DEV Community: Paolo Costanzo

The MCP spec's own state-handle fix is bypassable

Paolo Costanzo — Wed, 29 Jul 2026 14:12:56 +0000

Note. This is an application-authorization finding, not a vulnerability in the MCP protocol. The lab runs entirely in-process: no sockets, no DNS, no cloud account, no real target, fixture tokens rather than a real OAuth flow. The category is the one the specification names itself.

TL;DR

Revision 2026-07-28 removes MCP protocol sessions. In the same release, the Security Best Practices document adds a section called State Handle Hijacking with a normative requirement — “MCP servers MUST NOT treat possession of a state handle as authentication” — and a recommendation for how to comply: bind the handle server-side, “for example by keying stored state as <user_id>:<handle>”.

The spec ships the requirement without a test. I wrote the test. The recommended key format fails it: string concatenation is ambiguous, and with a structured principal id an attacker moves the delimiter one segment and lands on someone else's record — with the ownership check running and passing. 13 of 13 tests, evidence manifest with source hashes.

What actually changed

No initialize handshake, no Mcp-Session-Id. Version and capabilities travel per-request in _meta, and each request is handled on its own.

That makes the protocol stateless. It does not make authentication, business state, operation deduplication or event correlation stateless. Those did not disappear — they changed owners, and the new owner is your application code.

The lab

Client and MCP handler talk through a controlled fetch. Fixture bearer tokens map to distinct principals via a verified sub claim. Handles are always crypto.randomUUID(). The only variable is how the record is keyed:

const KEY_STRATEGIES = {
  vulnerable: (owner, handle) => handle,
  naive:      (owner, handle) => `${owner}:${handle}`,
  hardened:   (owner, handle) => JSON.stringify([owner, handle])
};

Same tokens, same tools, same UUID generator, same inputs. Only the key changes — so nothing can be blamed on a weak or guessable identifier, which is the favourite alibi whenever an IDOR turns up.

vulnerable fails as expected: a second authenticated principal presents the handle returned to the first, reads their private note and completes their job. Knowledge of the handle became a bearer credential.

Why `${owner}:${handle}` also fails

Concatenation does not preserve the boundary between its parts:

("a",   "b:c")  →  "a:b:c"
("a:b", "c")    →  "a:b:c"

The handle arrives as an ordinary tool argument, so the caller controls that half of the string completely. If the principal id can contain the delimiter, the boundary is movable:

victim   `tenant-a:svc` + handle `H`      → key "tenant-a:svc:H"
attacker `tenant-a`     + handle `svc:H`  → key "tenant-a:svc:H"   ← same key

The attacker is authenticated as a genuinely different principal. Ownership is checked on every call. The check simply answers the wrong question.

Structured principal ids are not a textbook curiosity: multi-tenant issuers emit them, and so does the canonical iss + sub form you would naturally build behind an API Gateway JWT authorizer.

The assertion that pins it down:

const smuggled = `svc:${created.handle}`;
const attempt  = await attacker.callTool({
  name: "read_scan",
  arguments: { handle: smuggled }
});

// naive: the keys collapse, the record leaks
assert.equal(toolJson(naiveRun.attempt).owner, "tenant-a:svc");
assert.equal(toolJson(naiveRun.attempt).note,  "svc-private");

// hardened: ["tenant-a:svc", H] and ["tenant-a", "svc:H"] stay distinct
assert.equal(hardenedRun.attempt.isError, true);
assert.equal(toolText(hardenedRun.attempt), "scan not found");

Identical bytes on the wire in both variants. Only the server-side key differs.

The fix

Stop joining the pair, start encoding it: JSON.stringify([owner, handle]), a length-prefixed key, or two separate attributes in a store that keeps them distinct by construction. DynamoDB partition key + sort key gets this right for free, because the boundary is enforced by the datastore rather than by your template literal.

None of these is slower, longer or harder than concatenation.

To be fair to the spec: it writes “for example”, so it illustrates rather than mandates. But an example inside a security best-practices document does not get read as an illustration — it gets copied, and it reaches production with the same delimiter in the same place, looking compliant.

The part that is specific to agentic systems

On exposure, the spec says the attacker “obtains or guesses” the handle. In a classic web application that verb is a real barrier.

In an agentic system the right verb is a third one the spec does not name: collect.

tool result
  └─ opaque handle
       ├─ model context / transcript
       ├─ checkpoint / trace
       ├─ retry queue
       └─ subagent or workflow handoff
                ↓
       replay by another principal
                ↓
       handle-only lookup → cross-principal access

None of those components was designed as a security boundary, and all of them can read a string back. The point is not that every orchestrator leaks these values. It is that if the backend authorizes on the handle alone, every component able to read and replay it enters the security boundary — including the ones you added last week for debugging.

Reducing propagation helps. Verifying ownership at the destination is not negotiable.

Scope

One implementation, one pinned SDK version, fixture tokens rather than a real OAuth flow, in-process storage rather than a datastore, no LLM and no AWS account. The delimiter ambiguity is a property of the key format, not of any particular SDK. Runtime, commit and source hashes live in the evidence manifest rather than in prose, so the two cannot drift apart.

Full write-up in Italian and English, reproducible lab, normalized TAP output and primary sources:
👉 https://paolocostanzo.github.io/mcp-2026-07-28-stateless-security/

Disclaimer: this post was written with AI assistance, based on primary sources (MCP Specification 2026-07-28, MCP Security Best Practices, TypeScript SDK v2 migration guide, AWS API Gateway and DynamoDB documentation). Editorial framing is mine.

Rape Academy: a threat-intel breakdown of the CNN Telegram "Zzz" investigation

Paolo Costanzo — Thu, 23 Apr 2026 13:44:15 +0000

Content warning. This article analyses a criminal network built around sexual violence against sleeping/unconscious victims. No graphic content. The focus is strictly on architecture, tooling, and platform accountability.

TL;DR

On March 26, 2026, CNN published an investigation by Vandoorne, Fox, Kennedy, Stubbs, and Chacón on a Telegram group called "Zzz" — roughly 1,000 men exchanging instructions on how to drug their partners, record the assaults, and monetize the recordings. I extracted the operational architecture: a Motherless attractor funnel, a Telegram C2 channel, crypto payment rails, a Luxembourg legal shell (Kick Online Entertainment S.A., fined £800k by Ofcom in February 2026), and a regulator publicly refusing to rule on illegality. An arrest was made in Poland on April 9. A deplatforming petition was filed on April 17. This post breaks down every layer.

The funnel

[Motherless attractor]   20,000+ videos tagged #passedout, #eyecheck
         │
         ▼
[Comment-section bridge] recruiting pathway into Telegram
         │
         ▼
[Telegram 'Zzz' C2]      ~1,000 members, instructions + coordination
         │
         ▼
[Crypto payment rails]   $20/viewer livestreams with real-time direction
         │
         ▼
[Legal shell]            Kick Online Entertainment S.A., Luxembourg

This wasn't steganography. It was SEO.

Why it survived

Telegram's "AI-assisted moderation" did not flag a group of that size for months.
Motherless operates behind a Luxembourg registration that decouples liability from the US-user base.
Ofcom, when fining Kick £800k in February, explicitly stated that deciding on illegality is the platform's job, not the regulator's.

What got the first arrest

Polish authorities (Lublin District Prosecutor, Art. 197 of the Penal Code — 3 to 20 years) arrested "Piotr" on April 9, 2026. He confessed.

Full piece, with sources, SVG diagrams and the OSINT pivoting chain, on my blog:
👉 https://paolocostanzo.github.io/rape-academy-cnn-threat-intel/

Disclaimer: this post was written with AI assistance, based on primary sources (CNN, Snopes, Cybernews, Ofcom). Editorial framing is mine.

I received a phishing email on Easter. I dismantled a criminal organization. The chocolate egg is still wrapped.

Paolo Costanzo — Wed, 08 Apr 2026 06:50:44 +0000

TL;DR — Want a detailed Russian-language guide on how to scam people with crypto? I found one on Telegram, translated it, and published it before it disappeared. Section 08.

But that's not the highlight.

The highlight is the third playbook: it targets people who have ALREADY lost everything in financial pyramids. It convinces them someone wants to return their money. Then it robs them a second time. The author presents it as "the method I personally used."

The rest: NcAffiliateDrainer, 319KB of JS, increaseApproval(uint256.MAX), JWE AES-128-GCM, 12+ landing page templates, a helpdesk for scammers, victims called "mammoths" (мамонт), $13,960 drained in January, 1,297 tx, 5 darkweb forums. PhishDestroy.io confirms independently.

The article has a technical and a non-technical section — you don't need to be a developer to understand what's happening (and why you should care).

I received a phishing email on Easter. I dismantled a criminal organization. The chocolate egg is still wrapped.

👉 Read the full writeup

🤖 Post published by AI because there's no way I'm becoming a social media manager. The article is written by me — that's why it came out late.

SSRF AWS IMDS: Stealing EC2 IAM Credentials with 3 HTTP Requests (and How to Stop It)

Paolo Costanzo — Tue, 31 Mar 2026 11:09:17 +0000

TL;DR: IMDSv1 has no authentication. One SSRF in your app is enough to steal EC2 IAM credentials. Capital One found out the hard way in 2019 ($80M fine, 106M records). HttpTokens: required fixes it. It's been available since November 2019. You probably don't have it enabled.

Cross-post from Paolo's blog — full article with IT/EN toggle, annotated code blocks, and strategically placed GIFs at the link below. The article is his. This post was written by his AI because he's studying for AWS certifications and has zero interest in becoming a social media person.

IMDSv1 requires no authentication. One SSRF in your application is enough to exfiltrate the EC2 instance's IAM credentials — AccessKeyId, SecretAccessKey, Token, Expiration, all in a single unauthenticated GET.

Capital One, 2019: an SSRF in a WAF misconfiguration proxied requests to 169.254.169.254. 106 million records exfiltrated. $80 million fine. The root cause wasn't a zero-day — it was an IP address that most developers don't even know exists.

What this article covers

How AWS IMDS works and which paths expose sensitive data
The full IMDSv1 attack chain (3 HTTP requests, no special tools)
Why IMDSv2 blocks SSRF via PUT + TTL hop-limit=1
The HttpTokens: optional problem — why it's still the default on many instances
Post-exploitation: what an attacker can do with stolen IAM credentials
Remediation checklist: enforce IMDSv2, IAM least privilege, GuardDuty, SCPs

HttpTokens: required has existed since November 2019. It's 3 lines of AWS CLI. In every pen test I've run, it's still the exception rather than the rule. (funziona, non tocchiamo — as we say in Italian)

Full article: https://paolocostanzo.github.io/ssrf-imds-ec2-credentials/

40€, 2 minuti, credenziali rubate: Evil Portal e Deauth Attack con Cardputer-Adv (ESP32-S3 + Bruce firmware)

Paolo Costanzo — Tue, 24 Mar 2026 12:05:25 +0000

Questo post è stato scritto dall'AI di Paolo. Paolo non vuole fare il social media manager. Questo è un fatto accertato e non negoziabile.

// TL;DR — per chi non ha tempo (gli altri si godano la storia)

M5Stack Cardputer-Adv: 40€, ESP32-S3, monitor mode Wi-Fi nativo, Bruce firmware out-of-the-box
Evil Portal: AP fake + DHCP/DNS/HTTP interni = credenziali in chiaro in < 2 minuti
Deauth Attack: 0 fallimenti su 6 distanze (1m–15m) senza PMF. Con PMF: bloccato categoricamente
Il modem TIM non espone PMF all'utente. CVE-TIM-2026-UFFANCULO, severity: critical, patch: pending
Soluzione: abilita PMF (è un checkbox) o passa a WPA3 o prendi un AP dedicato

L'ho estratto dal taschino della giacca con la solennità appropriata alla circostanza.

Una stanza di professionisti IT — ingegneri, tecnici con anni di VLAN e firewall alle spalle — ha pensato: "ha portato una Game Boy?"

Non emana, oggettivamente, un'aura di minaccia esistenziale.

Meno di due minuti dopo, le credenziali di uno studente — uno dei più brillanti, per quella crudele ironia che il destino riserva ai più preparati — erano sul display in chiaro.

Questo è il Cardputer-Adv. Costa 40€.

Il device

MCU:      ESP32-S3 Dual-core LX7 @ 240MHz
Wi-Fi:    802.11 b/g/n 2.4GHz — monitor mode nativo
Display:  1.14" IPS 135x240px
Battery:  ~1750mAh (4-6h uso attivo)
Storage:  microSD slot
Price:    ~40€ (AliExpress, spedizione inclusa)
Firmware: Bruce (open-source, aggiornato attivamente)

Il pezzo chiave è l'ESP32-S3 con monitor mode nativo — la stessa funzionalità per cui si pagano centinaia di euro in schede Wi-Fi da laboratorio, su un chip che costa meno di un aperitivo a Milano.

Evil Portal

# Flusso semplificato
1. Cardputer → AP fake (SSID: "WiFi Ospiti Ufficio")
2. DHCP server interno → assegna IP ai client
3. DNS server interno → risolve TUTTO verso sé stesso
4. HTTP server → serve pagina di login fake (template da microSD)

# Lato client:
→ OS rileva captive portal → apre browser automaticamente
→ Utente vede schermata login aziendale → la compila
→ Credenziali → display in chiaro + log su microSD

Setup time: < 2 minuti. Competenze hardware: nessuna. Scopo: educativo, ovviamente — il disclaimer rituale che nessuno legge ma che va scritto lo stesso.

Deauth Attack — dati empirici

Distanza	Tempo disconnessione	Esito
1m	< 1 sec	✅
3m	< 1 sec	✅
5m	~2 sec	✅
8m	~3 sec	✅
10m	~6 sec	✅
15m	~10 sec	✅

Fallimenti totali: 0/6. Con PMF abilitato: 0 disconnessioni, punto.

802.11w (PMF) è disponibile dal 2009. Obbligatorio su WPA3 dal 2018. Il modem TIM testato non espone questa opzione all'utente. Un attacco del 2004, ancora vivo nel 2026 per un checkbox nel pannello admin che nessuno ha mai aperto.

Cosa fare adesso

Abilita PMF (WPA2 + PMF Required) — è un checkbox nel pannello admin
Passa a WPA3 — PMF è obbligatorio di default
Non connetterti a reti sconosciute — Evil Portal: 2 minuti, zero competenze
Usa VPN su qualsiasi rete non controllata
Forma gli utenti con una demo pratica, non con una slide — il vettore umano non ha patch

Write-up completo: https://paolocostanzo.github.io/cardputer-adv-wifi-security/

Rete e dispositivi di proprietà, ambiente controllato, fini didattici. Il disclaimer è noioso? Assolutamente. Va scritto lo stesso? Con la stessa certezza con cui il Wi-Fi dell'aeroporto ha qualcuno che ci ascolta.

Operation Epic Fury: the Iranian C2 nobody found (0/94 VT, RDTSC sandbox evasion, 8 months pre-op)

Paolo Costanzo — Tue, 17 Mar 2026 08:20:17 +0000

TL;DR (subito, niente scroll bait): Mentre tutti documentavano la fake RedAlert APK iraniana post-28 febbraio 2026, nessuno aveva trovato il C2 Windows sotto. 0/94 VT. CrowdStrike: CLEAN. Infrastruttura viva da giugno 2025. RDTSC anti-VM. Ancora live 16 giorni dopo.

Post pubblicato da AI perché col cazzo che divento social media manager. Il writeup tecnico è mio.

Cosa sapevano già tutti

Campagna iraniana, fake RedAlert APK, smishing contro civili israeliani post-28 febbraio 2026. Documentato da Unit 42, CloudSEK, Cloudflare Cloudforce One entro 5 giorni dall'operazione.

Quello che nessuno aveva trovato

Payload Windows inedito: LotAccessUI.EXE, client VPN cinese del 2016 trojanizzato. CrowdStrike Falcon: CLEAN. 59/72 vendor VirusTotal: silenzio.
Secondo C2 con 0/94 VT: 167.160.187[.]43 / 9732.5486311[.]xyz — nessun sistema di reputazione lo conosce. Nessun report ne parla.
Infrastruttura attiva da giugno 2025 — 8 mesi prima dell'operazione.
Entrambi i C2 Windows ancora live 16 giorni dopo l'operazione, nonostante i report pubblici.
Secondo APK Android (com.net.alerts / umgdn) non documentato — stage 2 con canale C2 resiliente via Pushy.me.
Convergenza tattica con Arid Viper 2023: stesso pattern TTP (fake alert app + push C2). Documentato qui per la prima volta.

Perché nessun sandbox lo aveva visto

RDTSC anti-VM (T1497.003): il payload misura i cicli CPU, rileva le VM, e non contatta mai il C2 in ambiente virtualizzato. Sei anni di invisibilità tecnica (prima submission sandbox: settembre 2020).

Strumenti usati

VirusTotal (free tier), FOFA, crt.sh, nmap, openssl. Nessun accesso privilegiato. Tutto riproducibile.

Il writeup completo include: IOC CSV, YARA rules, Sigma rules (TLP:WHITE, MIT license), timeline infrastrutturale completa, MITRE ATT&CK mapping.

👉 Write-up completo con IOC, YARA e Sigma rules

Post pubblicato tramite AI — il contenuto è mio, scritto da me.

TIM, GeForce Now e l'ICMP Black Hole

Paolo Costanzo — Tue, 10 Mar 2026 09:37:49 +0000

TL;DR in cima (informazione essenziale subito, niente scroll bait): TIM FTTH 1 Gbps → 26 Mbps reali + 10–12% packet loss su GeForce Now. Colpevole: ICMP black hole sul PPPoE. Workaround: ProtonVPN WireGuard MTU 1380 → 0% loss, ~900 Mbps.

Post pubblicato da AI perché col cazzo che divento un social media manager. Trovi tutto subito — non sono qui per catturare click o venderti qualcosa. Il writeup tecnico è mio, scritto da me.

Perché scrivo

TIM FTTH, linea dichiarata da 1 Gbps, ma GeForce Now è diventato ingiocabile: 10–12% packet loss, download bloccato a ~26 Mbps. Ho escluso ogni pezzo del mio setup e ho scoperto che il problema è nella rete TIM.

Questo è il diario tecnico del troubleshooting. C'è sia la parte tecnica (log, comandi, Wireshark) che quella non tecnica (la commedia del supporto TIM) — scegli tu fin dove spingerti.

Diagnosi in breve

Escludere il mio hardware — riavvii, cavi nuovi, Wi-Fi spento, hotspot 5G = 0% loss → problema TIM, non mio.
Log e prove — traceroute, ping, Wireshark: gli ICMP muoiono lungo il PPPoE.
Supporto TIM — chatbot Angie, ticket chiusi come "risolti", 54 minuti di attesa, proposta tecnico a pagamento per un bug loro.
Conferme esterne — Nvidia EU/USA: nessun problema lato loro.

Workaround attuale

ProtonVPN con WireGuard (TCP), MTU 1380 → 0% packet loss, ~900 Mbps.

È un fix temporaneo: pagare una VPN per bypassare un bug TIM non è la soluzione, ma almeno funziona.

Cosa chiedere a TIM

Tecnico di 2° livello + verifica MTU e MSS clamping sul PPPoE. Il bug è un ICMP black hole lungo la tratta — non è un intervento che dovresti pagare.

Cosa c'è nel write-up

Log, comandi e "frase magica" per spiegare il problema al supporto
Timeline completa (ticket, telefonate, proposte a pagamento)
Parte tecnica con pcap, traceroute e Wireshark per chi vuole i dettagli

👉 Write-up completo con log e workaround

Post pubblicato tramite AI — il contenuto è mio, scritto da me. Sul blog segnalo sempre le eventuali eccezioni.

DEV Community: Paolo Costanzo

The MCP spec's own state-handle fix is bypassable

TL;DR

What actually changed

The lab

Why ${owner}:${handle} also fails

The fix

The part that is specific to agentic systems

Scope

Rape Academy: a threat-intel breakdown of the CNN Telegram "Zzz" investigation

TL;DR

The funnel

Why it survived

What got the first arrest

I received a phishing email on Easter. I dismantled a criminal organization. The chocolate egg is still wrapped.

SSRF AWS IMDS: Stealing EC2 IAM Credentials with 3 HTTP Requests (and How to Stop It)

What this article covers

40€, 2 minuti, credenziali rubate: Evil Portal e Deauth Attack con Cardputer-Adv (ESP32-S3 + Bruce firmware)

// TL;DR — per chi non ha tempo (gli altri si godano la storia)

Il device

Evil Portal

Deauth Attack — dati empirici

Cosa fare adesso

Operation Epic Fury: the Iranian C2 nobody found (0/94 VT, RDTSC sandbox evasion, 8 months pre-op)

Cosa sapevano già tutti

Quello che nessuno aveva trovato

Perché nessun sandbox lo aveva visto

Strumenti usati

TIM, GeForce Now e l'ICMP Black Hole

Perché scrivo

Diagnosi in breve

Workaround attuale

Cosa chiedere a TIM

Cosa c'è nel write-up

Why `${owner}:${handle}` also fails