Hi! I’m Matias Fumega, security consultant at Kulkan Security. This post covers my research on the Govee H8630 smart display. Starting from initial UART access and ending at full device impersonation over MQTT, finding and reporting cool bugs along the way.

Introduction

Govee smart displays are consumer IoT devices running embedded Linux (Tina Linux, based on OpenWrt) on ARMv7 hardware.

This investigation started as a curiosity exercise. The initial goal was simply to obtain a root shell. Once inside, the scope expanded naturally: firmware update endpoints, the authentication scheme protecting them, certificate storage, and the MQTT channel connecting the device to Govee’s AWS-hosted broker. The device analyzed is a Govee H8630 display.

Physical Access and UART Shell

UART is a serial protocol that sends data one bit at a time over two wires (TX and RX) plus ground. Both sides must agree on a baud rate beforehand since there’s no shared clock. That’s it, it’s the simplest possible communication channel. Here we usually see debug logs, the kernel logs, and sometimes, we get a shell.

The device exposes a 4-pin serial header on its main board, with pins individually labeled:

The connection to a UART-USB adapter follows the standard cross-wiring (device TX → adapter RX, device RX → adapter TX).

The device uses an uncommon baud rate. The majority of devices use 115200.

picocom -b 1500000 /dev/ttyUSB0

At 1,500,000 baud, the screen printed readable boot messages. From here, pressing “Enter” drops us into an interactive shell, but the session is immediately flooded with continuous debug output messages.

Obtaining a Usable Shell

As soon as the system fully loads, and we get an interactive root shell, there are tons of log messages originating from the govee_app process (PID 330).

I tried to kill it first, but there was a watchdog script continuously monitoring for its presence and launching it again if it was not running, so a direct kill triggered an immediate restart loop.

Suspending the process instead was the correct approach:

kill -STOP 330

This silences the debug output and frees the terminal. The display stops updating until the process is resumed or the device reboots, but the shell becomes fully interactive:

Persistence Across Reboots: OverlayFS

With a root shell available but no known root password, I changed it with the passwd command. This enabled Telnet access (port 23) without requiring physical UART access each time.

My question at this point was whether this password change would survive a power cycle.

Rebooting the device confirmed it persisted, and the reason lies in the mount configuration:

mount | grep " / "
overlayfs:/overlay on / type overlay
(rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/workdir)

The root filesystem is an OverlayFS. The lowerdir is the read-only factory image (squashfs). The upperdir=/overlay/upper is a writable layer stored in flash memory. Any modifications, including /etc/shadow, are written to the upper layer and persist across reboots unless a factory reset explicitly clears them.

Here is a good image to understand how this FS operates. Lowerdir, in our case, is the / directory. So everything there is gonna be RO . But the trick is that we are “adding” an upperdir, which is a writable flash space. And the “overlay” layer will be the combination of the lower and upper directories.

The result is we’ll have all the firmware and critical data as RO, and a writable layer for all the modifications. Bear in mind that all these modifications will typically be wiped after a hard reset.

Factory Reset Mechanism

The govee_init.sh script, located at /etc/init.d/ launches a binary called govee_reset at boot. Analysis of this binary in Ghidra revealed a hardware-triggered factory reset handler function.

This function, opens /dev/gpiochip0 and monitors a GPIO pin (line 0x24) via ioctl calls. If the pin is held low for more than 5 seconds, the following commands execute sequentially:

/govee/others/stop_app.sh
find /data -type f -exec rm {} \;
find /mnt/UDISK/data -type f -exec rm {} \;
fw_setenv parts_clean rootfs_data:UDISK
reboot

This wipes the /data partition and sets a U-Boot environment variable to signal a clean partition on next boot. The OverlayFS upper layer resides within /data , meaning a factory reset does erase the password change, but only if the physical reset button is held long enough to trigger this path.

Now that we have an idea on how the device manages this, let’s try to find a way to download the firmware.

Firmware Update Mechanism

After moving around within the device filesystem, I ended up opening the file /data/config/system_config.ini which contains several cloud endpoints, including the OTA URL:

I tried a simple GET request to the /firmware/check endpoint, but it wasn’t successful. The response was:

{“status”:405,”message”:”Method Not Supported”}

So, from this, I knew that a POST request, and maybe a structured body would be required. In order to find out all the body parameters, we’ll have to dive deep into a binary called govee_iot.

Let’s get to it.

Reversing the OTA Request Body in govee_iot

My first approach here was to look for the string https:// within all the binaries, and it partially worked, because after a few hours, I found this particular one: https://%s/bff-iot/device/v1/config/endpoint. By tracking this down in Ghidra, it led me to another function in charge of sending the request to this endpoint.

The JSON body is assembled by FUN_0003e994 using cJSON:

Here’s an organized table with the field and the function in charge of crafting it.

The /data/config/device_config.ini file supplies the following device fields:

[device]
uuid = D2:…:CC
ble_mac = …
sku = H8630
ble_hw = 5.01.00
ble_sw = 1.00.79

UUID Construction

The device UUID is an 8-byte colon separated value. Similar to a MAC address but two bytes longer. Searching the firmware binaries for the string uuid revealed the following format string fw_setenv govee_uuid %02x-%02x-%02x-%02x-%02x-%02x-%02x-%02x,%08x inside govee_iot , tracing to a couple functions that after understanding what was going on, I ended up with the following UUID structure:

UUID = [2 random bytes] + [BLE MAC address reversed]

The gid Field

The gid field is not a static identifier, it is an AES-128-ECB ciphertext produced at runtime.

The function validates the magic bytes of the file /data/config/gid/gid.bin against the constant 0x55e3202a. If matches, the check is successful, otherwise, throws an error.

The origin of this constant is unknown; it appears to be a vendor-defined magic number.

The value is in little-endian format, so it is read in reverse byte order.

After validating, it copies the value and then performs AES encryption.

After tracking in Ghidra this code for a while, I found that the 16-byte AES key is assembled from three device-specific components:

[ SKU prefix (up to 8 bytes) | 4 ASCII chars of UUID | last 4 ASCII digits of timestamp ]

After understanding how the GID was built, I built a script to automate this task from now on:

from Crypto.Cipher import AES

sku = b"H8630"
uuid = b"[REDACTED]"
timestamp_ms = 1757934206123

key = bytearray(16)
key[:len(sku)]  = sku[:8]
key[8:12]       = uuid[:4]
key[12:16]      = str(timestamp_ms)[-4:].encode()
key = bytes(key)

gid_raw = b"U@91c480cbf57af5a9cd65a5dd567b596f09d547a524c98723db0e497c6efdf615"
pad_len  = (16 - (len(gid_raw) % 16)) % 16
plaintext = gid_raw + b"\x00" * pad_len

cipher    = AES.new(key, AES.MODE_ECB)
encrypted = cipher.encrypt(plaintext)
print(f"[+] Final GID: {encrypted.hex()}")

Up to this point, I was able to complete my JSON like this:

{
"chip": 81,
"sku": "H6630",
"device": "{REDACTED}",
"wifiHardVersion": "5.01.00",
"wifiSoftVersion": "1.00.79",
"bleHardVersion": "5.01.00",
"bleSoftVersion": "1.00.79",
"timestamp": {currentTimestamp},
"gid": "{Obtained by our script}",
"signature": "????"
}

The signature Field

The function FUN_0003e824 constructs the signature. It formats a string from device fields and passes it to another function in charge of the HMAC-MD5 implementation.

This function takes an input buffer, uses a secret key stored at 0x4a395 of length 0x10 and then runs the HMAC-MD5.

After several failed attempts to reproduce the signature, I paused the analysis and decided to find a workaround.

After exhausting all kinds of approaches, the solution came from the least glamorous method. It turns out, sometimes the best reverse engineering tool is just… reading the logs.

The exact input string was recovered by reconnecting via UART, restarting govee_iot, and searching the debug output for the hmacMd5_buf log entry.

The device logs just printed the exact field order:

Sending Authenticated OTA Requests

I first saved this one to a file called “firmware_check.json” and tried sending a curl request to the /firmware/check endpoint.

curl -sS 'https://device.govee.com/bff-iot/device/v1/ota/firmware/check' -H 'Content-Type: application/json' -H 'envid: 0' -H 'iotversion: 0' --data-binary @firmware_check.json

And I received the following response:

{
"message":"success",
"checkVersion":{
"needUpdate":false,
"channelType":0,
"chip":81,
"sku":"H8630",
"device":"[REDACTED]",
"md5":"",
"fileType":1,
"size":0,
"versionSoft":"1.00.79",
"versionHard":"5.01.00",
"downloadUrl":""
},
"status":200,"data":{"dst":{"deviceDst":[],"timezoneID":"","sync":0}}}

The hypothesis was that reporting an older software version would trigger a “needUpdate:true” response, so I changed the “versionSoft”:”1.00.79" , to “versionSoft”:”1.00.00" , and it worked:

[...]
"downloadUrl":"https://s3.amazonaws.com/govee-public/upgrade-pack/6a77267aa18f69e1de61db758376984d-H8630_WIFI_HW5.01.00_SW1.00.79_OTA.swu"
[...]

Obtaining this way the correct endpoint to download my device’s firmware. A plain S3 URL, unauthenticated, with no signature, no expiration, and no access control. Anyone with the URL can download it.

The /config/endpoint

With the body confirmed and the signature function reversed, I finally had everything needed to sign requests correctly.

This was the script I end up with:

import hmac, hashlib

KEY = b"&k2#@.<7oQ;>Y)l+"  # 16-byte ASCII key

def signature(p: dict) -> str:
    msg = (f'{int(p["chip"])}.'
           f'"{p["gid"]}"."{p["sku"]}"."{p["device"]}".'
           f'"{p["wifiHardVersion"]}"."{p["wifiSoftVersion"]}".'
           f'"{p["bleHardVersion"]}"."{p["bleSoftVersion"]}".'
           f'{int(p["timestamp"])}.{int(p["saltVersion"])}')
    return hmac.new(KEY, msg.encode(), hashlib.md5).hexdigest()

payload = {
"chip": 81,
"sku": "H6630",
"device": "[REDACTED]",
"wifiHardVersion": "5.01.00",
"wifiSoftVersion": "1.00.79",
"bleHardVersion": "5.01.00",
"bleSoftVersion": "1.00.79",
"timestamp": 1757366722,
"saltVersion": 3,
"gid": "123123123",
}
print(signature(payload))

Sending a message with arbitrary values but a valid signature confirmed that the server only validates the signature structure, not the content.

Note: A random device fails with “Unbound device”; binding is enforced separately from the signature.

The signature validates the structural integrity of the request body, but it does not grant access to arbitrary device identifiers. Sending a properly signed payload with a random device value returns an error:

{“status”: 400, “message”: “Unbound device”}

Device binding is enforced server-side independently of signature verification. A valid signature is necessary but not sufficient. The device field must correspond to a device that has been provisioned and bound to a Govee account. This limits the practical impact of the hardcoded HMAC key to devices whose UUIDs are already known.

The /config/endpoint endpoint is particularly interesting, because it returns device configuration data.

Here’s the body in JSON format to see in an easy way the content:

{"status":200,
"message":"Success",
"data":{
"timestamp":1757446397,
"serverTime":1757446397305,
"mqttPort":8883,
"mqttAddress":"aqm3wd1qlc3dy-ats.iot.us-east-1.amazonaws.com",
"certificate":{"certificatePem":"-----BEGIN CERTIFICATE-----
","privateKey":"-----BEGIN RSA PRIVATE KEY-----"},
"subscribe":{"gdTopic":"GD/[REDACTED]"},
"publish":
{"accountTopic":"GA/[REDACTED]","gdTopic":"RT/thin
g/server/GD/[REDACTED]/data/report"},
"urls":{
"otaUrl":"https://device.govee.com/bff-
iot/device/v1/ota/firmware/check",
"matterCertUrl":"https://device.govee.com/bff-device/v1/ota-cert",
"weatherUrl":"https://device.govee.com/bff-iot/v1/third-api/weather",
"financeBtcUrl":"https://device.govee.com/bff-iot/v1/third-api/finance-
btc-usd",
"nbaGameUrl":"https://device.govee.com/bff-iot/v1/third-api/nba/game",
"multimediaUrl":"https://device.govee.com/bff-iot/device/v1/multimedia",
"uploadFileUrl":"https://device.govee.com/bff-
iot/device/v1/file/upload",
"uploadFileUrlV2":null,
"nflGameUrl":"https://device.govee.com/bff-iot/v1/third-api/nfl/game",
"financeStockPriceUrl":"https://device.govee.com/bff-iot/v1/third-
api/finance/stock-price"}
}}

See the MQTT data and the Private Key? I decided to quickly explore both, which you’ll see in the sections below. Before diving in, let’s quickly cover what MQTT actually is.

MQTT Analysis

MQTT (Message Queuing Telemetry Transport) is a lightweight publish-subscribe messaging protocol designed for low-bandwidth, high-latency, or unreliable networks. It’s everywhere in IoT.

MQTT was not the primary focus going in. So the following findings arose from exploring the device’s cloud communication stack.

From the file /data/config/system_config.ini I pulled some connection details, such as the URL, port, Sub and Pub Topics.

This whole protocol, for this case, works as follows:

• Govee display -> MQTT client. Publishes telemetry data, but can also subscribe to receive commands.
• Govee cloud/server -> MQTT broker. Receives what the device sends and routes it to subscribers (like the app).
• Govee mobile app -> Another MQTT client. Subscribes to the device’s topic to get updates, and can also publish commands (brightness, mode changes, etc.) back to the device through the broker.

To interact manually with this protocol, I used Mosquitto, a client tool for MQTT.

My first attempt was the simplest possible. But mosquitto_sub immediately prompted that a topic was required.

At that point I started digging inside the device to figure out which credentials were required, and in case I couldn’t recover them, I had another potential lead to follow: a response from /config/endpoint that returned a private key and certificate.

Decrypting Certificates and Private Key

I saved the Certificate and private key to a file, but when I tried to use them with mosquitto_sub, it failed again.

Running file on them showed they were not plain PEM files. Both were reported as binary data. Opening them revealed they were encrypted.

After inspecting the govee_iot binary, I found a function in charge of decrypting these files, but this function exposed the hardcoded key and IV used for encryption/decryption, which are critical for retrieving the device’s private key.

userKey = (uchar *)FUN_00027fd4("2b05705d5c46f412af8cbed55aadeeee");
ivec = (uchar *)FUN_00027fd4("02a85c61c786def4521b060265e8eeee");

Based on this new info, I wrote a Python script to decrypt my cert and privkey files.

#!/usr/bin/env python3
from Crypto.Cipher import AES
import sys
# Hardcoded key and IV from firmware
key_hex = "2b05705d5c46f412af8cbed55aadeeee"
iv_hex = "02a85c61c786def4521b060265e8eeee"

key = bytes.fromhex(key_hex)
iv = bytes.fromhex(iv_hex)

def decrypt_file(enc_file, out_file):
with open(enc_file, "rb") as f:
data = f.read()
# AES-128-CBC decrypt
cipher = AES.new(key, AES.MODE_CBC, iv)
decrypted = cipher.decrypt(data)
# Strip possible padding (\x00 or PKCS#7)
decrypted = decrypted.rstrip(b"\x00")
with open(out_file, "wb") as f:
f.write(decrypted)
print(f"[+] Decrypted {enc_file} -> {out_file}")

if __name__ == "__main__":
if len(sys.argv) != 3:
print(f"Usage: {sys.argv[0]} <encrypted_cert.pem> <encrypted_privkey.pem>")
sys.exit(1)
decrypt_file(sys.argv[1], "cert-fixed.pem")
decrypt_file(sys.argv[2], "privkey-fixed.pem")

We can check this doing the file command on the 2 new files:

With this, I performed the same Mosquitto command we used before, but this time it worked! and asked for a client ID. The client ID is the identification of our Govee device for example. I could do a complete valid request like this, and successfully subscribe:

With this, I could impersonate the device and look for commands by interacting with the app and listening to that sub topic:

Responsible Disclosure

After completing the analysis, I reported the findings to Govee’s security team, covering the hardcoded HMAC-MD5 key, the AES key and IV used for certificate encryption, and the device impersonation primitive enabled by combining both.

Govee acknowledged the report and on January 21st 2026 confirmed the vulnerabilities were remediated.

Conclusion

What started as getting a root shell ended up exposing a full device impersonation primitive.

The individual findings are not exotic. But hardcoded keys and an open serial console are common IoT weaknesses. What makes this interesting is how they chain, allowing me to impersonate the device completely.

The most impactful fix would be per-device key derivation for both the HMAC signature and the certificate encryption, rather than firmware-wide constants. The server-side device binding check provides a partial mitigation, but it relies on UUID secrecy. A weak assumption once physical access is achieved.

Matias Fumega [LinkedIn]
Security Consultant @ Kulkan

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe

Hi! I’m Matias Forti, technical lead at Kulkan Security. In this post, we’ll dive into some research focused on Evilginx, a popular reverse proxy phishing toolkit. We’ll look at how these AitM attacks work, how Evilginx tries to stay hidden, and most importantly, how we can detect and disrupt these campaigns in the wild.

Disclaimer: This blog and the underlying research targets the community version of Evilginx 3, it’s likely that most of the fingerprinting methods we’ll look at in this post will not work as described on the pro version.

Brief intro to AitM Phishing

Adversary-in-the-Middle (AitM) phishing attacks work by proxying traffic between a victim and a legitimate service, capturing credentials and session tokens in real-time. Unlike traditional phishing pages, AitM phishing can bypass MFA by proxying the entire authentication flow.

Evilginx 3

We’ll be briefly going over Evilginx 3 (by @kgretzky) one of the most popular AitM phishing toolkits, the full documentation on how it works can be found here, but we’ll cover the essentials.

At its core, Evilginx is a reverse HTTP proxy, written in Go, designed to transparently intercept and relay traffic between a victim and a legitimate site, it’s designed to be modular and easily tailored to different targets by using Phishlets, which we’ll look at next.

Phishlets

Phishlets are how you define and configure what pages will be Phished, including what domains / subdomains to spoof, what cookies or headers to capture and even custom Javascript injection on proxied pages.

Below is a sample phishlet designed to steal a PHP session cookie from “supersecretauth.r3tro.sh”:

Once a Phishlet is loaded Evilginx will generate the corresponding certificates to match any defined domains / subdomains, then wait for the Attacker to start the campaign.

Lures

Lures are what Evilginx calls the final Phishing URL sent to the victim, they include a randomly generated 8 character code that tracks a given phishing attempt:

This token not only serves to track a given phishing session but also as a pseudo-authorization token, as any attempt to visit the phishing page without the corresponding token will redirect clients away from the Evilginx instance, this is one of many steps Evilginx takes to hide itself from potential scanners, which we’ll look at next.

How Evilginx hides / how we can find it anyway

As mentioned before, any attempt to interact with the Evilginx instance outside of a valid Lure URL will result in the client getting redirected away, this defaults to the RickRoll youtube video, but can be customized to any other url:

Notably, even though the URL can be customized, by default the surrounding HTML will stay the same, so this can serve as a very crude fingerprint.

But it doesn’t stop there, after redirection the Client’s IP Address will be placed on a blacklist, blocking any further connection attempts. This blacklist can also be populated before Evilginx starts, to preemptively block any known scanners.

However there’s a really simple way to bypass this, given that inside the code handling the HTTP proxy and the logic for the blacklist we can find the following lines:

The first fragment deals with handling Proxy forwarding headers, setting the origin IP address to then one passed in the header. The “IsWhitelisted” function handles a special whitelist case, where the local IP “127.0.0.1” is always whitelisted.

Combined, this functionality provides a really simple way to bypass the blacklist, by manually setting a proxy header to “127.0.0.1” as pictured below:

With this we can fully interact with the Evilginx instance, bypassing the blacklist. Theoretically, this would allow us to brute force a valid Lure id, but since it’s 8 random alphanumeric characters the search space is still too big to correctly guess the correct Lure id. So we’ll quickly go over some additional fingerprinting methods.

TLS Certificates

Since Evilginx creates all the certificates for each subdomain assigned for the phishlet, the simultaneous creation of multiple certificates, specially ones matching a known Phishlet pattern, can be a really good indicator that a given domain is an Evilginx instance, tools like crt.sh are really helpful for this:

Unfortunately for this method, plenty of online guides exist on how to configure Evilginx to use a wildcard certificate instead, this also seems to be a feature of Evilginx Pro.

Machine Learning Proxy detection

The brilliant research at Catching the Transparent Phish by researchers at Stony Brook university and Palo Alto networks, goes over building a machine learning model that can accurately tell whether or not it’s connected to a proxied server.

Importantly, this profiling is done at the network level, so it does not require knowing the correct Lure endpoint to determine if a given site is a Evilginx instance or not.

TLS Fingerprints — JARM

Similarly to the above research, it’s possible to get a JARM fingerprint of an Evilginx instance without knowing the corresponding Lure endpoint:

The screenshot above shows the generated JARM for a test Evilginx instance we setup, it’s worth noting that the JARM will change based on the Go version used to build Evilginx so it can’t be used as a long lived indicator, but it could be useful to quickly identify multiple instances in a given time period.

DNS

Evilginx instances host their own DNS server with some interesting functionality that we can use as a fingerprint, specifically:

• The DNS server will resolve any subdomain of the Phishing domain to the set IP, whether it’s defined in the Phishlet configuration or not
• The DNS server will not respond to attempts to resolve any other domains

As an example, here’s how this looks for a local Evilginx instance, with the phishing domain set to “test.local” and using the example Phishlet, that sets up the subdomain “academy.test.local”:

The DNS server is not affected at all by the blacklist, so there’s no need to worry about our IP getting blocked when profiling it this way.

With that we’re done with the Evilginx specific fingerprinting methods, however the “normal” indicators still apply to Evilginx instances such as domain age and reputation, name similarity to the phished site, and of course if you have access to the correct Lure looking at the served HTML to see if it matches the Phished site.

Extra — Fun with ANSI

While looking into the possibility of guessing valid Lures I noticed that the Log output for Evilginx URL decodes the accessed endpoint before showing it to the user:

Since this is a CLI application I started trying to mess with ANSI escape codes and unsurprisingly they worked:

Given that these logs are shown every time an unauthorized request is made, and in combination with our blacklist bypass from before, this gives us the capability to perform a, mostly harmless, attack by spamming the server with some fun ANSI codes, as shown below:

Conclusion

This wraps up our brief investigation into how to find Evilginx servers, while individually any of the methods shown can’t fully identify an instance, combining them together serves as a powerful way for finding and blocking Evilginx servers before they can do any damage, and maybe messing with the Attackers a bit with ANSI injection.

Matias Forti [LinkedIn] [X]
Technical Lead @ Kulkan

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe

Cisco’s new model release extends their previous 8B model with structured reasoning capabilities. This allows it to generate explicit reasoning traces and think through complex, multi-step security problems before presenting an answer.

If you have an Ollama deployment, you might have noticed this model isn’t in the library yet, and there are no GGUFs available on Hugging Face (as of time of writing this!).

In this article I’ll show you how to take the raw weights, pack them into a compressed GGUF, and run the model locally, ensuring you don’t have to trust a random internet stranger to pack the files for you.

And we’re going to do this using docker, so that you don’t have to install and persist software that you don’t plan on using, and we have it run sandboxed, the attacker-mindset way.

If you haven’t packed a model before, it’s a great excuse to get hands-on with tensors, GGUF and a tiny step forward in your supply chain security practices. It only takes a few minutes (give or take based on your connection speed).

Download the Weights and settings/configs

Go to the official repo and list all files: https://huggingface.co/fdtn-ai/Foundation-Sec-8B-Reasoning/tree/main

Doing this manually won’t require any Huggingface Tokens or API keys.

Now place all of the downloaded files in a local directory named “raw_model” (should you use a different name then update it in the commands below as well)

Files you actually need:

• All “.safetensors” files, “config.json”, “generation_config.json”, “tokenizer.json”, and “special_tokens_map.json”.

Packing into GGUF

This section assumes you have Docker installed. The command below will convert the downloaded files into a well packed GGUF. For more information on the GGUF format please refer to: https://huggingface.co/docs/hub/en/gguf

The command assumes you’ve downloaded all required files to a raw_model subdirectory and you’re executing this from the parent directory.

docker run --rm -v $(pwd):/data python:3.11-slim bash -c " \
  apt-get update && apt-get install -y git && \
  pip install --upgrade pip && \
  git clone https://github.com/ggml-org/llama.cpp.git /app/llama.cpp && \
  pip install -r /app/llama.cpp/requirements.txt && \
  python /app/llama.cpp/convert_hf_to_gguf.py /data/raw_model --outfile /data/foundation-sec-F16.gguf"

As a result, you’ll now have “foundation-sec-F16.gguf” file in the parent directory. You’re almost there! Read the next section in order to learn how to compress its size in a way we don’t lose quality or sanity (err, precision).

Quantasizing, A.K.A. Compressing our GGUF

The GGUF that we have is already usable, but it will likely require more VRAM that you and I have, or more than you’d be willing to allocate for the model.

That’s why we want to first Quantasize the model, whilst remaining careful not to reduce its size to a point where we make it “dumb”.

So how much should we be able to reduce its size in this case? In this example, I’m quantizing to Q8_0, which is well above the standard Q4_K_M normally used for 8b parameter models; just “in case” considering this new reasoning behavior may require higher precision to work properly. Higher precision should ensure the “chain of thought” logic remains intact.

Note that I have not found official recommendations from Cisco on which compression would be acceptable for us mortals with limited VRAM.

Here’s a quick table Gemini Pro put together for us:

Let’s use docker then to quantize to Q8_0:

docker run --rm -v $(pwd):/data ghcr.io/ggml-org/llama.cpp:full \
  --quantize /data/foundation-sec-F16.gguf /data/foundation-sec-Q8_0.gguf Q8_0

Once the process finishes successfully, we’ll see a new GGUF in the same directory as the original one, named “foundation-sec-Q8_0.gguf”.

You may also notice the GGUF is half the size as the original, yay!

Importing to Ollama

We’re now going to be putting together a “Modelfile” which is going to be used by Ollama to load our GGUF file and in it we’re also going to be referencing data obtained from the huggingface files downloaded earlier.

DIRECTIVE IN MODELFILE            SOURCE OF DATA
--------------------------------------------------------------------------------
FROM ./path_to_model.gguf         The path to the GGUF file.

TEMPLATE …[llama3.1template]      Meta Llama 3.1 Standard (This is because this
                                  model provided by Cisco is derived from 
                                  Llama-3.1-8B-Base).

PARAMETER temperature 0.6         Llama-3.1-FoundationAI-SecurityLLM-Reasoning-8B
                                  Technical Report (Specific to the "Reasoning"
                                  variant). Refer to https://arxiv.org/html/2601.21051v1#S4
                                  section Evaluation Results > Evaluation Protocol.
                                  (Also, note that the README file provided by 
                                  Cisco mentions 0.3 was used for Benchmarking 
                                  purposes).

PARAMETER top_p 0.95              Llama-3.1-FoundationAI-SecurityLLM-Reasoning-8B
                                  Technical Report. Refer to 
                                  https://arxiv.org/html/2601.21051v1#S4 section
                                  Evaluation Results > Evaluation Protocol.

SYSTEM …[system prompt]           Obtained from tokenizer_config.json provided by
                                  Cisco, under the “chat_template“ property.

PARAMETER stop "<|user|>"         Obtained from tokenizer_config.json provided
PARAMETER stop "<|assistant|>"    by Cisco and then eot_id is just standard for
PARAMETER stop "<|system|>"       Llama.
PARAMETER stop "<|end_of_text|>"
PARAMETER stop "<|eot_id|>"

Create a file named “Modelfile” in the same directory as the GGUF:

FROM ./foundation-sec-Q8_0.gguf

# 1. The Cisco/Jinja Chat Template
# (Derived directly from the tokenizer_config.json)
TEMPLATE """{{ if .System }}<|system|>
{{ .System }}
{{ end }}{{ if .Prompt }}<|user|>
{{ .Prompt }}
{{ end }}<|assistant|>
"""

# 2. The OFFICIAL System Prompt also obtained from tokenizer_config.json
SYSTEM """You are Metis, a cybersecurity reasoning model from the Minerva family developed by Foundation AI at Cisco. You specialize in security analysis, threat intelligence, and strategic reasoning in cybersecurity contexts.

The user is a cybersecurity professional trying to accomplish some cybersecurity task. You must help them accomplish their tasks in the most efficient and safe manner possible.

You have professional knowledge and experience of a senior-level cybersecurity specialist. For tasks relating to cyber threat intelligence (CTI), make sure that the identifiers (CVEs, TTPs) are absolutely correct.

Think step-by-step before producing a response. Explicitly generate a reasoning trace to explain your logic before your final answer."""

# 3. Parameters (From Technical Report & Tokenizer)
PARAMETER temperature 0.6
PARAMETER top_p 0.95
PARAMETER stop "<|user|>"
PARAMETER stop "<|assistant|>"
PARAMETER stop "<|system|>"
PARAMETER stop "<|end_of_text|>"
PARAMETER stop "<|eot_id|>"

Note: Ollama does not run the GGUF file directly from your source directory. Instead, adhering to the OCI (Open Container Initiative) standard, it ingests the file and converts it into hashed ‘blobs’ stored in its internal registry. Therefore once the import is complete, your original GGUF file is redundant and can be deleted to save space

Place both the GGUF file and the “Modelfile” in a temporary location of your choosing, and run:

ollama create foundation-sec -f Modelfile

We’re ready to try it out.

Run:

ollama run cisco-fsec-reason "I can't find the question to the answer 42"

Closing thoughts

We are in an era where open-weight models are gold. Being able to pack and run them yourself means you aren’t reliant on third parties or stuck paying for expensive closed-source APIs.

Privacy Reminder: If you use this locally to analyze sensitive logs or internal configs, cut the cord. Ensure your inference server has outgoing internet access blocked. One main advantage of local AI is privacy, don’t leak your reasoning traces by accident.

Thanks for reading!

Lucas Lavarello

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe

How to Run Cisco’s Foundation-sec-8B-Reasoning in Ollama (DIY Guide!) was originally published in Artificial Intelligence in Plain English on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello, Serafin Cepeda here, Security Consultant at Kulkan. If, like me, you have invested effort in configuring SPF, DKIM and DMARC for securing the e-mail setup of a domain in the past, you might have struggled with the settings on each DNS Record whose syntax and options can not only be difficult to remember but also not trivial to understand.

A few command-line tools and scripts which are out there take care of parsing and validating said records from a security point of view; but none produce a human-readable output with recommendations for the setup. That’s the reason why I decided to create mxchecksec, following the latest industry standards. And today I’m sharing the tool with you, reader. I sincerely hope it helps you to secure your setup!

SPF, DKIM and DMARC Records

Simple Mail Transfer Protocol (SMTP) is the foundational protocol for transmitting email across networks, but it was originally designed under the assumption that the use-cases would be trustworthy, and that there would not be users with malicious intentions trying to take advantage of the protocol design. SMTP does not have built in security mechanisms that prevent spoofing or spam so, to overcome this, extra authentication protocols have been designed to verify the legitimacy of email senders and ensure message integrity.

Those security mechanisms are SPF, DKIM and DMARC, and even if SMTP itself does not require them to work, nowadays major email providers like Google mandate some configurations (e.g. DMARC to be present/configured for senders with over 5.000 emails a day), and all three are essential for high deliverability and protection against cyberattacks. Without SPF, DKIM and DMARC, legitimate emails could be flagged as spam or even be rejected by major providers, yet most importantly, the domain could become vulnerable to impersonation and phishing attacks. Let’s take a closer look at each of those protocols to understand the protection that each one provides, and the potential risks on the setup.

SPF (Sender Policy Framework) helps prevent email spoofing by specifying which IP addresses and servers are authorized to send emails on behalf of the domain. Upon receiving an email, the receiving servers check the sender’s IP address against the domain’s SPF record. If the IP is not authorized, the email may be rejected or marked as suspicious. This means that without SPF, an attacker could impersonate a sender and trick the recipient into taking action or disclosing information.

DKIM (DomainKeys Identified Mail) adds message integrity by digitally signing emails using a private key before they are sent, and that signature is stored in a header that is sent as part of the email itself. The receiving server verifies the signature using a public key published in the domain’s DNS records, ensuring that the email has not been altered during transit and confirming it originates from an authorized source. Unlike SPF, DKIM does not rely on IP addresses but instead uses cryptographic signatures to authenticate the message content and the sending domain.

DMARC (Domain-based Message Authentication, Reporting and Conformance) relies both on SPF and DKIM by enforcing policies for handling emails that fail authentication checks, and also enables domain owners to receive detailed reports about authentication failures, helping them monitor and improve their email security posture. So, while SPF and DKIM allows the domain owner to define mechanisms for authenticating the sending server and checking the integrity of the email, DMARC defines rules like “If the email fails the DKIM and SPF tests, then reject it, and report the result to reports@mydomain.com”.

Ok, now that we’ve covered the advantages each of the mechanisms brings, is it as simple as blindly creating each record in order to secure a domain? Well, not really, given that generic settings could still leave a domain vulnerable to attacks. For example, using a simple “+all” in the SPF record, would enable any IP address to send emails using that domain, or setting the DMARC policy with “p=none” might instruct to the receiving server to actually deliver to the user an email even if the SPF or DKIM validations fail. Therefore, the challenge is to come up with a configuration that enables trusted servers to send emails on behalf of the domain while preventing attackers from creating spoofed messages or sending spam using our servers; and right there is where some automated validations could help us!

Automated Validations

The tool that I’ve developed, and is available in GitHub, analyses the SPF, DKIM and DMARC records for one or multiple domains, parsing them as a receiving server would do, and checking if the resulting behaviour represents some kind of risk. With a single command you are able to validate if the records are properly defined and also if there is any misconfiguration that could represent a security risk.

The validations that I’ve implemented allow you to detect things like:

• Weak or Missing DMARC policies, that would allow spoofed emails with your domain to reach the Inbox of the recipients.
• Missing DKIM setup, or weak keys configured for the signing mechanisms.
• Missing or Weak SPF definitions, that might enable attackers to send spoofed emails.
• If the domain is not actively used for emails, it would detect if the setup is properly configured to prevent attackers from sending emails using that domain.
  This is important, because corporations will likely own multiple domains, and if proper records are configured only on the domain that is legitimately used to send outgoing email (eg. company.com) but not in every other domain that is actively used for other matters (eg. companyinc.com) attackers could simply go ahead and spoof the latter!

The tool will also try to identify the email provider in use, based on the MX Records configured, and, as DKIM requires a selector, it will also try to retrieve the selector for the domain by using a set of pre-defined and common selectors (but also enables you to define a custom selector for testing specific ones).

For example, the output for Google domain (google.com) which is properly configured:

And this is the output for a different domain that has configuration issues:

As you can see, the output is simple, yet human-readable and easy to understand, and provides details useful for mitigating the risks detected.

Get MxCheckSec today from:

• https://github.com/kulkansecurity/mxchecksec

Thank you for reading!

Serafin Cepeda [LinkedIn]
Security Consultant @ Kulkan

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe

MxCheckSec: Validate SPF, DKIM, DMARC, and more. was originally published in Cyber Security Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Inferring timezones based on Contributor disclosed Locations and pattern analysis on commit days and hours.

We added a new behavior/pattern analysis to detect suspicious or unusual commit timing, including:

• Automated/bot-style activity warnings (e.g., commit activity spanning more than 22 hours of the day, which could be normal behavior in Nomad contributors)

• Timezone inference across 190+ countries/cities. We simply collect the Location field bound to the account, match it to a Timezone and then inspect commit times to see if they are within a daylight window for that zone, or if they are night-time contributors, also mentioning if the Location does not seem to match the activity (it could be fake!)

The message varies, for example:

And it can help identify a potential incorrect or fake Location:

Obtaining more data by inspecting Commit messages and collecting co-authored-by trailers.

Gitxray now parses Co-authored-by: trailers in commit messages to collect additional contributor emails. Beyond simply extracting these co-authors, we also check whether co-authors are shared across commits from different accounts, helping uncover relationships that may not show up in standard author-only analysis.

We’re referring to these:

Which is picked up by Gitxray like this:

Repository creation-time warning

We included in v1.0.19 an additional check which can help signal malicious repositories with fake timestamps, by checking commit dates vs repository creation time, issuing a highlighted WARNING when the timeline doesn’t make sense.

If you’d like a good read on identifying fake and malicious repositories, refer to the following LinkedIn Post, where we used publicly available tools to create a fake account and fake repository, and then ran Gitxray against it:

• https://www.linkedin.com/pulse/gitxray-v1019-out-identifying-fake-github-personas-lucas-lavarello-8627f/

More on Gitxray at:

• https://github.com/kulkansecurity/gitxray
• https://www.gitxray.com/

Gitxray is also available in Kali! Check it out at:

• https://www.kali.org/tools/gitxray/

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

The goal of this post is to explore the nature of polyglot files and the scenarios where they are most effective for discovering vulnerabilities. We will also explore two existing tools which are going to help us create these kinds of files.

Learning the basics and how to use tools is valuable. However I firmly believe that taking that extra step to thoroughly understand the underlying mechanics, what they are actually doing and why, leads to a much deeper comprehension of any topic. This is exactly why I wanted to break this topic down step by step and with as much detail as possible.

Polyglot files

Starting with the main concept, these files are created by carefully structuring data so that different parsers interpret the same file differently. For example, a .png image might contain a hidden .exe payload, allowing it to behave as either an image or an executable depending on the context. This technique is commonly seen in malware distribution, but it’s also useful for bypassing file upload filters or exploiting weaknesses in file parsers.

Polyglot files work because attackers take advantage of overlaps between file formats and the way real-world parsers handle headers and structure. This becomes easier when a format tolerates extra bytes before or after the “content”, or when its signature doesn’t have to appear exactly at byte zero (that is the case, for example, of HTML). That said, the trick doesn’t depend on the embedded payload being a format with no magic bytes; it depends on making both parsers accept the same byte sequence.

Where polyglot uploads become risky

Polyglot upload testing is most valuable when the uploaded file is interpreted, transformed, or re-used by one or more components: server-side, client-side, or both. In practice, these processing paths are often not obvious from the outside, so it’s reasonable to prioritize testing whenever any of the following seem plausible:

• When an uploaded image or PDF is handled by image processing libraries or document parsers (CVE-2016–3714, CVE-2024–34790, CVE-2025–5138)
• When the metadata contained in a file is processed or manipulated by the server after the upload (CVE-2021–22204)
• When the file and, as a consequence, its extension, can be modified after it has been uploaded (CVE-2020–36847)

Examples and Useful tools to create polyglot files

Mitra

This tool automates the creation of polyglot files. It detects the two formats being combined, analyzes their structure and magic bytes, and identifies the chunks or segments each format allows. Based on that, it generates combinations where both formats can coexist within a single file. The tool supports the creation of these four categories of polyglots:

• Stacks: Simply appends one file after the other. Each parser reads only the part it recognizes and ignores the rest.
• Parasites: Injects file 2 into a location inside file 1 that allows arbitrary data without breaking its structure. This works if file1 has flexible or unused chunks.
• Zippers: Builds a file that is valid for both parsers simultaneously. It is created by overlapping the structures of file 1 and file 2, effectively “zipping” both formats together. The result is a more complex structure compared to parasite files.
• Cavities: Leverages “empty” or unused spaces within the primary file format to inject content from a second format. These spaces don’t affect the validity of the original file and can be used to hide or embed payloads.

As an example, we are going to create a PNG file which has an HTML embedded inside.

After executing Mitra, it shows that it was possible to create 2 types of combinations, a stack and a parasite file.

By inspecting the parasite file, it embedded the HTML file inside the PNG without corrupting it, using a “cOMM” chunk.

Let’s dive into why Mitra created this file the way it did, and why it can be interpreted in two completely different ways just by changing its extension.

According to the official PNG specification (RFC 2083), we know that this “cOMM” chunk is considered ancillary because its first character is lowercase (‘c’), which sets the ancillary bit to 1 (3.3 — Chunk Naming Conventions). Mitra simply took advantage of this and injected the payload inside this chunk.

Ancillary chunks are blocks of data whose contents are not strictly required to reconstruct or display the main image, and they can hold additional information while still keeping a valid PNG format (4.2 — Ancillary Chunks)

But here’s the interesting part: the “cOMM” chunk used here is not one of the officially defined ancillaries in the RFC.

So… what’s going on here??

This is where the magic happens: since “cOMM” is not part of the standard PNG specification, decoders will safely ignore any unknown ancillary chunk types and continue rendering the image normally (12.12 — Chunk Layout)

This behavior makes it possible to embed additional data such as an entire HTML file inside such a chunk without affecting how the image is rendered. As a result, the PNG remains visually intact, but it secretly carries an extra payload that may be interpreted differently depending on how the file is served or processed.

In contrast, if this polyglot is instead provided to an HTML parser such as a Browser and opened with a .html extension, the Browser will interpret the HTML tags contained in the injected chunk and render their content. For example, the image below shows JavaScript code being executed upon opening the polyglot file.

Moving on to the stack file, it simply concatenated both files.

We can also do this by just executing:

echo “<script>alert(‘XSS via polyglot!’)</script>” >> base.png

Since we’re forging a .png, the server would treat the file as an actual image. This becomes useful if the target application has image viewers that render the file or parse the image using vulnerable libraries or components.

This far, I have shown two files that could coexist, but now I want to go in the opposite direction.

I will show an example where two files are incompatible. This usually happens when one of the files strictly requires its signature to be located at the very beginning of the document, or precisely at offset 0x00, as it is the case with PNG files.

So, let’s see what happens when we try to create a PDF with a PNG file embedded inside. The result is the following:

In this case, Mitra indicates that the PDF can indeed embed another file starting at offset 0x30, which means right after the magic bytes and inside of an object element.

However, this is incompatible with PNGs, as this kind of files must strictly start at offset 0x00. You can think of it as the stricter file type defining the main structure and core of the polyglot, while the more flexible one (in this case, the PDF) is adjusted to fit within that structure. So what would actually be possible is creating a PNG that contains a PDF file inside, not the other way around.

Furthermore, if instead of attaching a PNG we use a simple .sh file, we can see that the payload is successfully injected inside the first PDF object at the specified offset.

By showing these examples we can conclude that any kind of combination fully depends on how flexible the formats are when being combined, from where the signature is required to be located, to which chunks can be used.

Github: https://github.com/corkami/mitra

ExifTool

There are specific scenarios where ExifTool becomes highly useful, particularly when the attack vector involves server-side manipulation of file metadata.

Consider the case of a file upload feature that only validates the magic bytes of the file, accepting only those matching a PNG header, but allows arbitrary extensions.

We could craft a PNG file (with valid magic bytes) but rename it to .php or .jsp and when uploaded, the server might later on interpret it as an executable (PHP/JSP) rather than an image.

Examples:

• <%= System.getProperty(“java.version”) %>
• <?php echo phpversion(); ?>

In this example we have a valid png structure and an embedded jsp payload in the file metadata.

Depending on what we are trying to exploit, we may obtain different outputs. If the metadata is displayed in the user interface, it is more likely that we will observe an XSS. On the other hand, if we embed a payload inside an image with the goal of extracting the PHP engine version, the response is more likely to appear in the server response when we request the path of the uploaded image. This is why being able to directly access the uploaded file is an added plus when exploiting these polyglot attack scenarios.

Github: https://github.com/exiftool/exiftool

MIME sniffing

When manipulating files, there’s an important concept to consider: MIME sniffing.

This occurs on the browser when, instead of trusting the Content-Type header provided by the server, it attempts to guess the file type by inspecting the magic bytes.

If we manage to upload a .png file (because only the extension is being validated) but the browser performs MIME sniffing, we could exploit this by crafting a .png whose initial content matches the signatures that browsers identify as HTML/JavaScript during MIME sniffing. This tricks the browser into interpreting our .png as HTML potentially leading to XSS vulnerabilities

In practice, modern browsers significantly restrict MIME sniffing, and many servers send the X-Content-Type-Options: nosniff header by default. However, misconfigurations still occur in real environments, and vulnerabilities continue to be reported when services fail to enforce this header. Some recent examples include:

• CVE-2024–43445
• CVE-2023–36918
• CVE-2018–17031

Conclusion

In conclusion, Polyglot files can be very sneaky, and they act as a reminder that “file type” can be an interpretation based on a lot of moving parts, very much tied to the complexity of the type of file being ingested and/or interpreted.

As we’ve seen, whether a combination works depends heavily on format flexibility: where magic bytes must appear, which chunks/sections can carry arbitrary data, and how strictly parsers enforce their own specs.

Just to briefly recap, exploitation opportunities may arise through:

• Metadata parsers
• Image processors
• Vulnerable libraries handling file content
• Web server misconfigurations that improperly execute uploaded files

And protecting ourselves against polyglots isn’t a simple task either. It’s an ongoing effort, because keeping parsers and processing libraries up to date matters just as much as validation logic. An effective remediation can involve implementing a Content Disarm and Reconstruction (CDR), which normalizes files by stripping or rebuilding risky structures before they’re stored or processed.

Three steps take place when a file is processed by a CDR. First, the file is disassembled into its core elements (headers, chunks, metadata, comments), and then only the components and attributes required for the legitimate functionality of the file are preserved. You can think of this technology as having a whitelist of which components make up a legitimate type of file (e.g. a PDF). Anything that does not match is removed. The file is then reconstructed using only the components that passed the filter.

Finally, I would like to acknowledge Ange Albertini, creator of the Mitra tool, and Phil Harvey, creator of ExifTool, for making such interesting resources available to the community. These tools inspired me to dive deeper into this topic and I highly encourage exploring their work.

Felipe Raczkowski Anaya [LinkedIn]
Security Consultant @ Kulkan

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe

Hello! I’m Matias Forti, technical lead here at Kulkan Security. As the AI landscape continues to evolve I’ve been really interested in exploring how these technologies can be attacked. This post will go over our research into remote MCP servers, covering the exposed attack surface and sharing our methods and ideas to test them.

DISCLAIMER: The MCP Specification is a new and evolving standard, it’s likely that the specification will change in the future and some of the items outlined in this blog will no longer be applicable. For reference this blog was written using the 2025–06–18 version of the specification.

Intro to MCP

We feel it’s important to briefly outline how the MCP Protocol works before going over to the attack surface of MCP Servers. While this quick explainer is good enough to follow the rest of the post, we greatly encourage you to read the complete specification to fully understand the protocol.

MCP (Model Context Protocol) is a lightweight protocol for giving large language models and agent frameworks safeish access to external data, tools, and resources. Instead of cramming everything into a single model prompt or an ad‑hoc API, MCP formalizes how a host LLM discovers what a remote or local server can do (prompts, resources, tools)

The specification describes 3 main participants:

• Host: The host LLM, such as Claude desktop or the Cursor IDE LLM.
• Client: The program used by the Host to communicate with the server, there will always be 1 client per server, and they should be isolated from each other.
• Server: The MCP Server itself, servers can be hosted either locally or remotely.

The transport layer is based on JSON RPC 2.0, sent via STDIN/STDOUT for local servers or SSE / streamable HTTP for remote servers.

The following diagram shows a sample configuration:

With that out of the way, we can look into the particulars of remote MCP servers.

Authentication / Authorization

MCP implements OAuth2 in the specification for remote servers requiring authorization, the MCP Server in this case acts like a resource provider, with a different service acting as the identity provider.

While not in scope for this blogpost, this means that remote MCP Servers could be affected by the known OAuth vulnerabilities.

After the OAuth handshake the server will set an authentication token which will be used in all following MCP requests. It’s worth noting that this token is not the same as the “Mcp-Session-Id” token which is used by the server to identify and track a given connection and not for identification.

A full overview of the Auth mechanism can be found here.

Attack surface

Remote MCP Servers can expose 3 fundamental services to clients; Tools, Resources and Prompts.

Prompts

Servers can expose prompts meant to be consumed by the host LLM, these prompts can optionally have arguments filled in by the user therefore acting as a sort of prompt table, these arguments can also include resource IDs, which will get bundled into the prompt.

Below is an example for the “prompts/list” operation:

From a security standpoint there’s not much here for us to attack, prompt injection could be possible if an attacker is able to tamper with the parameters passed to the prompt call, however that would require a way to include a prompt injection attack in a referenced resource or prior exploitation of the Host LLM / MCP Client to directly tamper with the parameters.

Resources

Resources are an MCP feature that allows servers to expose data and content that can be read by clients and used as context for LLM interactions.

The following requests show the interaction with Resources, first the client makes a call to the resources/list operation:

The client can then call a given resource by its URI:

This is a really clear vector for LFI or SSRF vulnerabilities, if the server is not validating that the URI passed by the client is one of the listed resources it could be tricked into disclosing internal files or services.

Additionally, for authenticated MCP Servers that expose resources bound to a given user this is a clear target for testing IDOR-like vulnerabilities.

Tools

Tools are the main selling point of the MCP protocol, and the most interesting from a security perspective, as they provide a way for LLMs (or us) to directly interact with code in the server.

For example, this is a simple tool definition using Python’s FastMCP library:

When a client calls the `tools/list` operation the tools’ contents will be returned with the following format:

This gives the client the input format expected by the tool, as well as a description on what it does, tools may also have optional parameters to give the clients’ extra context, these are defined here.

Clients will then call the tool according to the definition:

By their nature, tools provide a simple direct way to interact with code in the server, which means that, as attackers, they are the most likely targets for finding vulnerabilities.

As an example, Equixly research found that 43% of servers they tested were vulnerable to command injection vulnerabilities, among other security issues. It’s worth highlighting that interacting with remote MCP Servers is not fundamentally different from calling regular REST apis, so it’s reasonably expected that MCP servers are affected by the same type of vulnerabilities.

However, unlike REST apis, the asynchronous transport mechanism used by MCP servers makes it difficult for traditional security tools like Burp suite to interact with them, below we’ll show some tooling options that serve as a workaround:

MCP Inspector

https://github.com/modelcontextprotocol/inspector

MCP Inspector is a tool created by Anthropic to test and debug MCP Server, it provides a simple web user interface that lets us interact with a given server:

It supports all 3 transport methods (STDIO and HTTP via SSE or streamableHTTP) as well as OAuth authorization support.

There’s also a fully featured cli mode, useful for building automation scripts:

This tool is really helpful for the initial understanding and recon on MCP Servers, as well as for performing basic interaction.

MCP to HTTP Bridge

https://github.com/nccgroup/http-mcp-bridge

This tool written by NCC, as indicated by the name, is a simple bridge from the MCP SSE Protocol to the HTTP/1.1 protocol, meant to be used with a web proxy such as Burp Suite or Caido, with no fancy interface or tooling out of the box.

It’s important to note that as of writing, this tool only supports the SSE transport and not the streamable HTTP transport. The SSE transport was deprecated in the 2025–03–26 version of the specification, but it still seems to be supported by most publicly available MCP Servers.

Starting it requires passing the url for the MCP server we wish to connect to, it’ll then create a listener that we can point our proxy to:

Since this is basically a raw proxy, we’ll need to perform the MCP connection handshake manually to get a valid session-id to communicate with the server, instructions for this are available in the tool’s Github README page. Afterwards, we can interact with the MCP Server by crafting the appropriate JSON messages:

While this is more cumbersome, it gives us complete control over the message sent by the client as well as automation tools provided by the proxy itself, such as Burp Intruder.

Conclusion

While the MCP specification brings a novel interface for integrating LLMs with external systems, it also introduces familiar risks in a new format. Remote MCP servers present a clear attack surface that mirrors traditional web application vulnerabilities like command injection, SSRF, and IDOR.

As adoption of the MCP protocol increases (The MCP Servers Github page has over 500 listed official servers!) so will the need for us as security researchers to understand the protocol and become familiar with how to test it. Hopefully we have given you a good introduction into the inner workings of the protocol and how to get started with testing.

Matias Forti [LinkedIn] [X]
Technical Lead @ Kulkan

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe

Assessing the Attack Surface of Remote MCP Servers was originally published in Cyber Security Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hello! Lucas Cebrero here, Security Consultant at Kulkan. As part of an internal training activity I’ve been working on a small lab to learn about Client Side Path Traversal attacks. I wanted to share it with you along with a short blogpost. I hope that you enjoy it.

Introduction

Pentesters used to exploit CSRF almost everywhere with relative ease. Even when anti-CSRF tokens were introduced, secure implementations were hard to come by. Then came the SameSite cookie flag, which significantly raised the bar, and when browsers started setting SameSite to Lax by default, things got even harder.

The final blow seemed to come with applications that authenticate exclusively via header-based authentication methods such as JWTs in HTTP headers, as is commonly seen nowadays. Since these tokens aren’t automatically sent by the browser like cookies, the classic CSRF attack model no longer applies.

But a few years ago, a clever technique emerged that allowed pentesters to resurrect CSRF attacks in these auth header scenarios, Client-Side Path Traversal. I’d heard of this technique before, but decided to dive deeper, build the simplest possible lab, and understand exactly how it works.

Let’s take a closer look.

CSRF Protections

CSRF

First of all, why was CSRF such a widespread issue? Because browsers automatically included cookies in requests to a site whenever the cookie’s Origin matched the request site’s Origin, even if the request itself originated from a different site. If you’re unfamiliar with the concept of Origin, I recommend that you read Mozilla’s documentation over at: https://developer.mozilla.org/en-US/docs/Glossary/Origin

This expected behavior could be abused by attackers. If a user visited a malicious page while logged into another site, the attacker could trigger an authenticated request to that site, often performing state-changing actions, like updating an email address.

Anti-CSRF tokens

To defend against this, developers began adding anti-CSRF tokens. These are random values which are generated server-side and included in the requests made by users that the server has to verify before performing any action. For these tokens to be effective, they must be:

• Unique per user session.
• Secret
• Unpredictable (large random value generated by a secure method)

In practice, getting all these right is harder than it sounds, and insecure implementations have been common.

SameSite cookie flag

A newer browser defense is the SameSite cookie attribute, which controls whether cookies are sent with cross-site requests. It has three possible settings:

• None: cookies are sent with all requests, just like before.
• Lax: cookies are sent for same-site requests and safe cross-site requests like GET. They are not sent for POST, PUT, or DELETE from other Origins.
• Strict: cookies are only sent if the request originates from the exact same Origin (same protocol, host, and port).

Originally, this flag had to be set explicitly by developers. Now, modern browsers default to Lax if the attribute is missing, reducing CSRF risk for cookie-based authentication.

Authentication via HTTP headers (JWT)

Beyond SameSite cookies, many modern applications, especially Single-Page Applications (SPAs), have moved to using JSON Web Tokens (JWTs) for authentication. These tokens are typically stored in localStorage or sessionStorage and sent to the server via an Authorization header.

This approach eliminates the classic CSRF risk associated with cookies because:

• Unlike cookies, JWTs placed in the Authorization header are not sent automatically with every request to their Origin.
• JWTs in headers are only sent when the application’s JavaScript code explicitly adds them, making it impossible for a cross-site attacker to trigger an authenticated request without running code in the victim’s browser.

In other words, for a while, it looked like CSRF was finally dead in these “header-auth” scenarios. However, in 2022 an overlooked issue with seemingly low severity made it into PortSwigger’s Top 10 Web Hacking Techniques: Client-Side Path Traversal. Shortly after, Doyensec published their excellent research “Exploiting Client-Side Path Traversal: CSRF is Dead, Long Live CSRF”, which inspired me to take a closer look at this vulnerability.

What is Client-Side Path Traversal (CSPT)?

Modern Single-Page Applications (SPAs) rely heavily on the front-end. Routing, state management, and even sensitive operations like updating user profiles or changing passwords are often initiated entirely by JavaScript in the browser.

In these applications, the frontend code dynamically constructs API requests to send to the backend. For example, building a URL like /api/user/123/orders based on the route or query parameters in the current page like /#/orders/?userId=123.

This is convenient for development, but when user-controlled values are used in this path-building process without proper validation, an attacker can tamper with them to reach unintended endpoints.

Client-Side Path Traversal occurs when a frontend application takes a user-controlled path (or part of it), normalizes it, and sends it as part of an internal API request.

By manipulating this path, e.g., using ../ sequences, an attacker can make the frontend navigate to or call endpoints they shouldn’t suppose to.

Example:
https://test-site.local/#/profile?id=../../../../api/update-password

If the application’s JavaScript takes id and concatenates it into a request URL, it might end up calling /api/update-password without the user ever directly navigating there.

In this example, we’ll call “source” to the query parameter id and “sink” to the password update API /api/update-password.

The source is the attacker-controlled input that feeds into the vulnerable path construction.

And the sink, the sensitive or exploitable endpoint reached because of the traversal.

Why CSPT defeats JWT-in-header protections

Normally, an attacker can’t make the victim’s browser send a JWT in a request — unless they can run JavaScript in the victim’s Origin (e.g., via XSS).

But with CSPT, the attacker doesn’t need to inject code, they only need to trick the victim into visiting a crafted URL.

The frontend code itself will:

1. Resolve the manipulated path.
2. Send the request to the sink.
3. Automatically include the JWT in the Authorization header (or the header to use in common agreement between the client and the server).

From the backend’s perspective, it looks like a legitimate request from the authenticated user, a classic CSRF scenario brought back to life.

Walkthrough: Exploiting CSPT in the Lab

To really understand CSPT, I built a minimal vulnerable lab. The goal was to keep it simple enough to grasp the mechanics, but realistic enough to reflect issues you might find in modern apps.

The lab is available at:

• https://github.com/kulkansecurity/cspt-lab

Lab setup

• Frontend: React.js SPA
• Backend: Node.js REST API

Features:

• User creation, deletion, and modification with a validation feature.
• User profile viewing
• Admin panel to promote members to administrators

In real-world testing, very attractive CSRF targets would be the features for user deletion and user promotion. Because the app uses JWT authentication via HTTP headers, a classic CSRF which relies on cookie-based authentication is impractical. We wouldn’t be able to make the browser send the JWT for us unless… the frontend itself did it for us.

Finding a source

While browsing the app, a password confirmation feature can be found upon updating the email address. In a real system, this would send a confirmation link to the user’s email. However, in our lab, the link is simply displayed via a JavaScript alert().

When visiting this link, we can see that the frontend makes a request like:

fetch(`${config.apiBaseURL}/api/users/${userId}/profile`, {
  method: 'POST',
  headers: { 
    'Content-Type': 'application/json',
    'Authorization': `Bearer ${token}` 
  },
  body: JSON.stringify({ verified: true })
})

Here, userId is taken directly from the URL parameter with no sanitization nor validation and concatenated into the API path.

That’s our source.

From source to sink

If we replace userId with a traversal sequence ..%2f..%2f.. the resulting request path changes from /api/users/<id>/profile to /profile. And because the frontend still attaches the Authorization header, we can make it call any API endpoint the authenticated user has access to.

Crafting our exploit

The JavaScript code appends /profile to the request path. To remove it, we can append a # (fragment) or ? (query string) to our payload. The browser will treat anything after that as a fragment identifier or query string parameter respectively, excluding it from the path sent to the server.

There are two interesting endpoints in the backend that are perfect candidates to use as a sink.

The /admin/promote/<USER-ID> endpoint that promotes a user to admin, and the /users/<USER-ID>/delete which deletes a user.

Since the backend doesn’t care about extra parameters in the request body and only the path matters, we can target them directly.

The final payloads will look like the following:

Payload to promote

http://localhost.lan:3001/validate?userId=..%2fadmin%2fpromote%2fATTACKER-USERID%3f

Payload to delete

http://localhost.lan:3001/validate?userId=VICTIM-USERID%2fdelete%3f

When the victim clicks one of these links while logged in, the application’s own JavaScript:

1. Resolves the manipulated path.
2. Sends the request with the victim’s JWT in the Authorization header.
3. Executes the action without the victim’s consent.

In this example, an admin user clicked on the following URL, resulting in promoting an attacker with userId 092dc69583ca40b397cd7cd4485ddc4d

http://localhost.lan:3001/validate?userId=..%2fadmin%2fpromote%2f092dc69583ca40b397cd7cd4485ddc4d%3f

At this point, we’ve bypassed the JWT in header “protection” that comes as a consequence of using header-based authentication and pulled off a CSRF-style attack entirely via the frontend’s path handling.

Conclusion

As we can see, CSRF can still be exploitable through Client-Side Path Traversal, even with SameSite cookies and in applications that use header-based authentication. There’s no single silver bullet that fixes every case, so the safest approach is to avoid designs where client-side variables determine the request path sent to the server.

For applications that already rely on this pattern, it’s important to enforce strict validation on the backend by clearly defining which parameters and paths are expected, and by rejecting requests that include unexpected values. Doing so significantly reduces the likelihood of attackers finding a meaningful CSPT sink to exploit.

Additionally, client-side input validation is also useful because it adds another layer of complexity for an attacker. Even though client-side validation can be bypassed by modifying the DOM or altering the code, it’s unrealistic for an attacker to rely on a victim doing that themselves, which makes exploiting a CSPT through this vector significantly harder. Still, client-side validation should always be seen as a complement to server-side protections, not a replacement.

Lucas Cebrero Lell [LinkedIn] [X]
Security Consultant @ Kulkan

Resources:

• MDN Web Docs: SameSite cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite)
• OWASP CSRF Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html#rule---use-cryptographically-secure-pseudo-random-number-generators-csprng
• Doyensec CSPT to CSRF: https://blog.doyensec.com/2024/07/02/cspt2csrf.html
• Curated list of CSPT resources: https://blog.doyensec.com/2025/03/27/cspt-resources.html

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe

Hello everyone! Octavio Gorrini here, security consultant at Kulkan. As a way to continue learning I like to play CTFs, participate in challenges and share what we learn. Today we have a new write up on one of the “Yes We hack Dojos”, in this case, challenge #43. I hope you enjoy it.

The challenge description was the following:

“During a pentest, we discovered a rare custom Linux distro running a CCTV management program that seemed to be stuck in a boot process. If we could upload a custom firmware, we’d get remote code execution (RCE) on the CCTV. The rest was up to us”

Pretty straightforward: the goal was RCE. To begin with, I opened the provided files, and read the source code.

Note: In my opinion, one of the best things about YWH challenges is that you have access to the code, you can analyze it, find the vulnerabilities and exploit them. This helps not only to continue learning about pentesting techniques but also helps improve code review skills.

import time, yaml, random
from urllib.parse import unquote
from jinja2 import Environment, FileSystemLoader

template = Environment(
    autoescape=True,
    loader=FileSystemLoader('/tmp/templates'),
).get_template('index.html')
os.chdir('/tmp')

class Firmware():
    def __init__(self, version:str):
        self.version = version
    
    def update(self):
        pass

def genToken(seed:str) -> str:
    random.seed(seed)
    return ''.join(random.choices('abcdef0123456789', k=16))
def main():
    tokenRoot = genToken(int(time.time()) // 1)

    yamlConfig = unquote("")
    tokenGuest = unquote("")

    access = bool(tokenGuest == tokenRoot)

    firmware = None
    if access:
        try:
            data = yaml.load(yamlConfig, Loader=yaml.Loader)
            firmware = Firmware(**data["firmware"])
            firmware.update()
        except:
            pass
        
    print( template.render(access=access) )

main()

After reading the code I understood that:

• An authentication token was needed, tokenGuest in the code.
• Some sort of YAML payload was processed, yamlConfig.

We’ll see how these parameters are used below.

Analyzing the code

The first line that caught my eye was:

def genToken(seed:str) -> str:
 random.seed(seed)
 return ''.join(random.choices('abcdef0123456789', k=16))

This generated a pseudo-random 16-character “hex-ish” token based on a seed, but why “pseudo-random”? Because if you use the same seed, you get the same result.

Example: genToken(123) → ‘c46e63e00a07e28b’ (always the same).

Then later:

def main():
 tokenRoot = genToken(int(time.time()) // 1)
 access = bool(tokenGuest == tokenRoot)

The seed used is the timestamp in seconds. It compares the server’s token with the one we send. If they match → True, otherwise False. If access is True:

if access:
 try:
     data = yaml.load(yamlConfig, Loader=yaml.Loader)
     firmware = Firmware(**data["firmware"])
     firmware.update()
 except:
     pass

At high level, this could be simplified on:

• The code simulates a firmware update process.
• There is an access control check where the token sent by the user is compared against a token generated by the server.
• If the tokens are equal, the “update process” kicks in, loading the update with yaml.load(). This is where the code is vulnerable and can be exploited.

How can this be exploited?

• yaml.load() parses trusted and untrusted input the same way, potentially deserializing malicious objects directly. The documentation is very clear about how dangerous it is to use this method with untrusted data.
• So I can say “Hey, deserialize this object that calls os.system()” and Python will happily do it.
• The root cause of the bug is the use of yaml.load() which is dangerous when parsing untrusted input.

My attack plan was:
1. Predict the token using time.time() and random.seed(), to be able to reach the vulnerable code.
2. Time the request just right to pass the token check.
3. Send a malicious YAML payload to pop a shell (or at least run commands).

Hitting the rate limit

The first obstacle I faced was: rate limiting. If it wasn’t there, I could just brute-force millions of tokens per second and win. But the app blocked me. After testing, I realized it allowed ~1 request every 1.8 seconds. So I ditched Burp, wrote a custom Python script, and focused only on getting the right token first.

First attempt

My first “strategy” was pure chaos: trying to match the server’s time.time() with my local version, spoiler alert: Totally impossible. 😂 Then I thought: What if it’s just the timestamp in seconds?. Then, I should be able to predict it. I made a script to generate the next 10 tokens based on the next seconds trying to sync with the server, adjusting delays (2s, 2.2s…) hoping to land on the right second.

Example output:

[*] Next attempt at t=1753760457 with token: 56fa51386001fd7f
[-] Invalid token: 56fa51386001fd7f
[*] Next attempt at t=1753760462 with token: 1fc8d6a7222930d2
[-] Invalid token: 1fc8d6a7222930d2

No luck. After losing my mind, I gave up for the day and came back Monday night.

Second attempt: The latency trick

After more frustration (and fights with ChatGPT giving me weird ideas), it hit me: latency was the problem.

Those milliseconds between my machine and the server were messing up the exact timing needed. So I added a LATENCY_OFFSET. I tried negative offsets (-0.5, -0.45…), nothing. Then I tried positive offsets. At +0.2: BAM!!, valid token. From there, I changed my strategy: calculate t+3 seconds and send just that token in a loop.

[*] Loop mode: syncing every 3 seconds…
[*] Next attempt at t=1753882522 with token: 291bfc085714b6ec
[+] VALID TOKEN: 291bfc085714b6ec

Finally, access granted.

Putting all together: Exploiting the unsafe yaml.load()

Once I had access, RCE was easy. The payload that I used was:

YAML_PAYLOAD = quote('firmware: !!python/object/apply :os.system ["whoami"]')

The output received:

"output":"nobody"

Then I found this in the source:

import os
os.chdir('tmp')
os.mkdir('templates')
os.environ["FLAG"] = flag

The flag was in an environment variable. Perfect. So I changed my payload to:

YAML_PAYLOAD = quote('firmware: !!python/object/apply :os.system ["echo $FLAG"]')

An extra space character was added to the payload before :os.system to prevent a Medium autosave bug from triggering; otherwise Cloudflare blocks a Medium request to its “deltas” API.

And got:

[+] RESPONSE:
"output":"FLAG{M4lware_F1rmw4r3_N0t_F0und}"

Takeaways

Honestly, for me, it was a super fun challenge. These are perfect for practicing code analysis and exploitation. Things I learned:

• time.time() in Python is always UTC (I almost lost it thinking I had to do timezone math).
• How random.seed really works, not random at all if the seed is predictable.
• Rate limiting isn’t always about bypassing; sometimes it forces you to think differently.

Thanks for reading! I Hope you enjoyed the post, see you on the next one!

Octavio Gorrini [LinkedIn] [X]
Security Consultant @ Kulkan

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe

At Kulkan, we believe it’s essential to stay continuously informed about the latest security threats that could impact both our customers and the broader community. But in today’s fast-paced and evolving threat landscape, the recurring question remains: how do we keep up?

To help answer this, I’ve built a lightweight tool called ‘in4m’. Its purpose is simple: collect the latest security news from trusted, curated sources I frequently read, and present it in a clean, summarized format.

in4m is available in GitHub at:

• https://github.com/kulkansecurity/in4m

By default in4m retrieves news from the following sources:

• The Hacker News
• WatchTowr Labs
• Hackread
• Bleeping Computer

Here’s how in4m works:

• You choose your preferred sources from a preset list.
• The tool scrapes only the first page of each source to keep things short and quick.
• You can customize how many headlines to display and trigger scraping manually when needed, useful if you change your sources.
• To minimize redundant scraping, responses are cached locally and reused when the tool is re-run.
• You can include a keyword search to highlight keywords.
• Only titles are presented in the client. Links are provided to access/read the article in the original source.

While in4m is intentionally minimalistic, I have personally found it helpful for staying current with relevant news. Furthermore, it can be useful in a variety of scenarios. For example, a security researcher who has just published a CVE can quickly check if it has been picked up by well-known outlets, while blue team analysts might use it to stay ahead of breaking vulnerabilities, ransomware campaigns, or patch advisories.

I hope in4m helps you keep up with the latest news and trends!

Florián Reyes [LinkedIn] [X]
Security Consultant @ Kulkan

About Kulkan

Kulkan Security (www.kulkan.com) is a boutique offensive security firm specialized in Penetration Testing. If you’re looking for a Pentest partner, we’re here. Reach out to us via our website, at www.kulkan.com

More on Kulkan at:

• https://blog.kulkan.com
• https://x.com/kulkansecurity
• https://www.linkedin.com/company/kulkan-security

Subscribe to our newsletter at:

• https://kulkan.beehiiv.com/subscribe