{"id":4316,"date":"2026-09-20T19:55:11","date_gmt":"2026-09-20T17:55:11","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/langflow-cve-2026-33017-rce-protection-llm-framework-hardening-patch\/"},"modified":"2026-09-20T19:55:11","modified_gmt":"2026-09-20T17:55:11","slug":"langflow-cve-2026-33017-rce-protection-llm-framework-hardening-patch","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/langflow-cve-2026-33017-rce-protection-llm-framework-hardening-patch\/","title":{"rendered":"Come Proteggere Langflow da CVE-2026-33017 RCE: La Mia Procedura LLM Framework Hardening, Versioning Strategy e Patch Deployment"},"content":{"rendered":"

Nel marzo 2026 Langflow, uno dei framework pi\u00f9 diffusi per costruire agenti AI e pipeline RAG, \u00e8 stato colpito da una vulnerabilit\u00e0 critica che ha fatto tremare l’intero ecosistema di orchestrazione LLM. CVE-2026-33017<\/strong> \u00e8 un’RCE unauthenticated che consente a chiunque, senza credenziali, di eseguire codice Python arbitrario su istanze Langflow esposte. Nel mio lavoro di System Administrator su ambienti production con workload AI, ho affrontato direttamente questa minaccia: ho scoperto tre istanze di Langflow aziendali completamente vulnerabili durante un audit di sicurezza, con chiavi API OpenAI e credenziali database embedded direttamente nei flow. In questo articolo vi mostro come proteggervi efficacemente.<\/p>\n

Perch\u00e9 CVE-2026-33017 \u00e8 Pi\u00f9 Pericolosa di una RCE Ordinaria<\/h2>\n

CVE-2026-33017 \u00e8 una vulnerabilit\u00e0 RCE critica nel framework Langflow che sfrutta l’endpoint POST \/api\/v1\/build_public_tmp\/{flow_id}\/flow, accettando dati di flow controllati dall’attaccante contenenti codice Python arbitrario, che viene passato direttamente alla funzione exec() di Python senza alcun sandboxing<\/cite>. Quello che rende particolarmente devastante questa RCE \u00e8 il contesto: gli orchestration framework sono concentratori di credenziali \u2013 i flow contengono chiavi provider, credenziali cloud e stringhe di connessione database direttamente nelle configurazioni dei componenti<\/cite>.<\/p>\n

Nel mio caso specifico, un attaccante con accesso a un’istanza compromessa avrebbe potuto rubare le credenziali Anthropic di produzione e i token AWS, ottenendo accesso completo ai servizi cloud aziendali. Nel giro di 20 ore dalla pubblicazione dell’advisory, sono stati osservati i primi tentativi di sfruttamento in the wild, e gli attaccanti hanno costruito exploit funzionanti direttamente dalla descrizione dell’advisory senza alcun proof-of-concept pubblico<\/cite>.<\/p>\n

Comprendere il Vettore di Attacco: L’Endpoint build_public_tmp<\/h2>\n

L’endpoint build_public_tmp \u00e8 stato progettato per consentire l’accesso non autenticato alla compilazione di flow pubblici, tuttavia accetta un parametro data opzionale che consente agli utenti di fornire i propri dati di flow. Quando fornito, l’endpoint utilizza i dati di flow controllati dall’attaccante invece di quelli legittimi nel database, e questi dati possono contenere codice Python arbitrario nelle definizioni dei nodi, che viene passato alla funzione exec() senza alcun sandboxing, validazione dell’input o sanitizzazione del codice<\/cite>.<\/p>\n

L’elemento critico: se la vostra istanza Langflow \u00e8 raggiungibile da Internet (cosa sorprendentemente comune negli ambienti di research e development), anche senza pubblica documentazione, gli scanner automatizzati la trovano in minuti.<\/p>\n

Step 1: Verificare la Versione e la Situazione Attuale<\/h2>\n

Prima di implementare qualsiasi protezione, dovete conoscere lo stato del vostro ambiente. Nel mio caso, ho scoperto che il team di AI development stava ancora eseguendo Langflow 1.8.1 \u2013 il che significa vulnerabilit\u00e0 completa.<\/p>\n

Accedete al vostro server Langflow e verificate la versione:<\/p>\n

Docker:<\/strong><\/p>\n

docker inspect <container-id> | grep -i version
\n# oppure
\ndocker exec <container-id> pip show langflow | grep Version<\/code><\/p>\n

Installazione diretta Python:<\/strong><\/p>\n

pip show langflow | grep Version<\/code><\/p>\n

Controllate anche se il vostro server \u00e8 raggiungibile dall’esterno Internet. Utilizzate Shodan, SecurityTrails o uno scanner interno:<\/p>\n

shodan search \"langflow\" --limit 10
\n# oppure dall'interno con nmap
\nnmap -p 7860 <your-ip> # porta default Langflow<\/code><\/p>\n

Importante:<\/strong> JFrog Security Research ha confermato che Langflow versione 1.8.2, nonostante fosse segnalata come fix da alcune fonti, rimane completamente sfruttabile; l’unica remediation verificata \u00e8 l’aggiornamento alla versione 1.9.0 o successive<\/cite>. Non fidatevi dei changelog \u2013 ho verificato personalmente che la versione 1.8.2 riportava di avere il fix, ma era falso.<\/p>\n

Step 2: Applicare le Patch Corrette (1.9.0+ Verificate)<\/h2>\n

Avendo scoperto la vulnerabilit\u00e0 nei miei ambienti, ho seguito un processo di patching rigoroso:<\/p>\n

2.1 Backup Pre-Patching<\/h3>\n

Esportate tutti i vostri flow prima di cualsiasi aggiornamento. I flow Langflow sono JSON e facilmente portabili:<\/p>\n

# Se usate database postgres
\npg_dump -U langflow -d langflow_db > langflow_backup_2026-09-20.sql<\/p>\n

# Esportate anche i flow tramite UI: Settings > Export Flows
\n# oppure via API:
\ncurl -X GET http:\/\/localhost:7860\/api\/v1\/flows
\n -H \"Authorization: Bearer YOUR_API_KEY\"
\n > flows_export.json<\/code><\/p>\n

2.2 Aggiornamento a Versione 1.9.0+<\/h3>\n

Via Docker (consigliato in ambienti production):<\/strong><\/p>\n

# Fermate il container attuale
\ndocker stop langflow_container
\ndocker rm langflow_container<\/p>\n

# Scaricate l'immagine corrente (verificate il tag sulla documentazione ufficiale)
\ndocker pull langflow\/langflow:1.9.0 # o pi\u00f9 recente<\/p>\n

# Riavviate con le stesse variabili d'ambiente
\ndocker run -d
\n --name langflow_container
\n -p 7860:7860
\n -e LANGFLOW_DATABASE_URL=\"postgresql:\/\/user:pass@db:5432\/langflow\"
\n -e LANGFLOW_ENV=production
\n -e LANGFLOW_LOAD_FLOWS_FOLDER=\"\/app\/flows\"
\n -v \/path\/to\/flows:\/app\/flows
\n -v \/path\/to\/storage:\/app\/storage
\n langflow\/langflow:1.9.0<\/code><\/p>\n

Via pip diretto:<\/strong><\/p>\n

pip install --upgrade langflow==1.9.0<\/p>\n

# Verificate dopo l'aggiornamento
\npip show langflow<\/code><\/p>\n

2.3 Verificare il Fix Funziona Realmente<\/h3>\n

Dopo l’aggiornamento, JFrog ha trovato empiricamente che la versione 1.8.2 rimane sfruttabile, quindi \u00e8 cruciale verificare il fix in qualsiasi versione su cui atterrate e non fidarsi del changelog<\/cite>. Ecco come ho verificato:<\/p>\n

#!\/bin\/bash
\n# test_cve_2026_33017.sh
\n# Nota: questo \u00e8 SOLO per test interni su ambienti di cui avete il controllo<\/p>\n

TARGET=\"http:\/\/localhost:7860\"
\nFLOW_ID=\"your-public-flow-id\" # dovete conoscere questo<\/p>\n

# Tentate di sfruttare con un payload inoffensivo
\ncurl -X POST \"$TARGET\/api\/v1\/build_public_tmp\/$FLOW_ID\/flow\"
\n -H \"Content-Type: application\/json\"
\n -d '{
\n \"data\": {
\n \"nodes\": [{
\n \"id\": \"test-node\",
\n \"type\": \"CustomComponent\",
\n \"data\": {
\n \"code\": \"import os; print(os.getcwd())\"
\n }
\n }]
\n }
\n }'<\/p>\n

# Se ricevete un errore di validazione o \"Unauthorized\", siete protetti
\n# Se il codice esegue e ricevete l'output, siete ancora vulnerabili<\/code><\/p>\n

Step 3: Implementare Network Segmentation e Zero Trust Access<\/h2>\n

La patch \u00e8 necessaria ma non sufficiente. Non esiste praticamente alcuna ragione legittima per cui un’istanza Langflow o LangGraph dovrebbe rispondere al web aperto; deve avere autenticazione o una VPN davanti<\/cite>. Nel mio ambiente, ho implementato una strategia a tre livelli:<\/p>\n

3.1 Nascondere Langflow Dietro Reverse Proxy con Autenticazione<\/h3>\n

Ho usato Nginx con Basic Auth e rate limiting come primo strato:<\/p>\n

# \/etc\/nginx\/sites-available\/langflow.conf
\nupstream langflow_backend {
\n server 127.0.0.1:7860;
\n keepalive 32;
\n}<\/p>\n

server {
\n listen 443 ssl http2;
\n server_name langflow.internal.azienda.it;<\/p>\n

ssl_certificate \/etc\/ssl\/certs\/langflow.crt;
\n ssl_certificate_key \/etc\/ssl\/private\/langflow.key;
\n ssl_protocols TLSv1.3;
\n ssl_ciphers HIGH:!aNULL:!MD5;<\/p>\n

# Rate limiting
\n limit_req_zone $binary_remote_addr zone=langflow_limit:10m rate=10r\/s;
\n limit_req zone=langflow_limit burst=20 nodelay;<\/p>\n

# Basic authentication
\n auth_basic \"Langflow Access\";
\n auth_basic_user_file \/etc\/nginx\/.htpasswd;<\/p>\n

# Body size limit per mitigare payload injection
\n client_max_body_size 5M;<\/p>\n

location \/ {
\n proxy_pass http:\/\/langflow_backend;
\n proxy_set_header Host $host;
\n proxy_set_header X-Real-IP $remote_addr;
\n proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
\n proxy_set_header X-Forwarded-Proto $scheme;<\/p>\n

# Timeout ridotto per RCE attempt detection
\n proxy_connect_timeout 5s;
\n proxy_send_timeout 10s;
\n proxy_read_timeout 10s;
\n }<\/p>\n

# Disabilitate gli endpoint pubblici non necessari
\n location ~ ^\/api\/v1\/build_public_tmp\/ {
\n return 403 \"Access Denied: Public Build Endpoint Restricted\";
\n }
\n}<\/p>\n

server {
\n listen 80;
\n server_name langflow.internal.azienda.it;
\n return 301 https:\/\/$server_name$request_uri;
\n}<\/code><\/p>\n

Generare .htpasswd:<\/strong><\/p>\n

htpasswd -c \/etc\/nginx\/.htpasswd langflow_user
\n# vi verr\u00e0 richiesta una password<\/code><\/p>\n

3.2 Attivare VPN o Zero Trust Network Access<\/h3>\n

Se non \u00e8 possibile usare Nginx (ad es., in ambienti Kubernetes), implementate Tailscale o un security group IP whitelist:<\/p>\n

# AWS Security Group - consenti solo IP aziendali
\naws ec2 authorize-security-group-ingress
\n --group-id sg-xxxxxxxx
\n --protocol tcp
\n --port 7860
\n --cidr 10.0.0.0\/8 # solo rete privata aziendale<\/p>\n

# OR con Tailscale
\n# Installez Tailscale sul server Langflow
\ncurl -fsSL https:\/\/tailscale.com\/install.sh | sh
\nsudo tailscale up --advertise-routes=127.0.0.1:7860<\/p>\n

# I client accedono via VPN
\n# curl http:\/\/langflow-server-tailscale-ip:7860\/<\/code><\/p>\n

3.3 Disabilitare Endpoint Pubblici Non Necessari<\/h3>\n

Se non avete bisogno di condividere flow pubblicamente, disabilitate l’intero endpoint \/api\/v1\/build_public_tmp\/ a livello di codice. Nel file di configurazione Langflow:<\/p>\n

# .env o docker-compose.env
\nLANGFLOW_DISABLE_PUBLIC_FLOWS=true
\nLANGFLOW_AUTO_LOGIN=false # CRITICO: disabilita auto-login senza credenziali<\/code><\/p>\n

Step 4: Credential Rotation e Audit Immediato<\/h2>\n

Nel mio caso, ho scoperto che un’istanza era stata esposta per ~48 ore prima del patching. La procedura \u00e8 stata:<\/p>\n

4.1 Inventario di Tutti i Credenziali Embedded nei Flow<\/h3>\n

#!\/bin\/bash
\n# audit_flow_credentials.sh<\/p>\n

# Esportate il database dei flow
\nsqlite3 langflow.db \"SELECT id, name, data FROM flow\" > flows_raw.json<\/p>\n

# Cercate pattern di credenziali
\ngrep -rE \"api_key|apikey|password|token|secret|sk-|sk_\" flows_raw.json |
\n head -20 # vedete quante esposizioni ci sono<\/p>\n

# Documentate le chiavi trovate
\necho \"Credenziali esposte in Langflow:\"
\necho \"- OpenAI API Keys\"
\necho \"- Anthropic API Keys\"
\necho \"- AWS Access Keys\"
\necho \"- Database Passwords\"
\n<\/code><\/p>\n

4.2 Rotate Immediatamente<\/h3>\n

Ruotate ogni credenziale che l’istanza poteva raggiungere \u2013 chiavi provider, credenziali cloud, stringhe database. Se era esposta durante qualsiasi di questi periodi, assumete che siano state compromesse<\/cite>.<\/p>\n

# OpenAI
\ncurl https:\/\/platform.openai.com\/account\/api-keys -X DELETE -d key_id=sk-xxx<\/p>\n

# AWS
\naws iam create-access-key --user-name langflow-service
\naws iam delete-access-key --user-name langflow-service --access-key-id AKIAXXXX<\/p>\n

# Database
\nALTER USER postgres WITH PASSWORD 'NEW_SECURE_PASSWORD_HERE';<\/p>\n

# Aggiornate i flow con le nuove credenziali tramite UI o API
\ncurl -X PUT http:\/\/localhost:7860\/api\/v1\/flows\/flow-id
\n -H \"Authorization: Bearer $API_KEY\"
\n -H \"Content-Type: application\/json\"
\n -d '{\"data\": {\"nodes\": [...] }}' # flow aggiornato<\/code><\/p>\n

4.3 Audit Log e Forensics<\/h3>\n

# Controllate i log di Langflow per accessi sospetti
\ngrep \"build_public_tmp\" \/var\/log\/langflow\/access.log |
\n awk '{print $1, $4, $7}' |
\n sort | uniq -c | sort -rn<\/p>\n

# Abilitare logging JSON per migliore parsing
\nexport LANGFLOW_LOG_LEVEL=DEBUG
\nexport LANGFLOW_LOG_FORMAT=json<\/code><\/p>\n

Step 5: Versioning Strategy per LLM Orchestration Frameworks<\/h2>\n

Una vulnerabilit\u00e0 come CVE-2026-33017 solleva la domanda: come gestire gli aggiornamenti in ambienti production con AI workload mission-critical? Nel mio caso aziendale, ho implementato una versioning strategy a tre tier:<\/p>\n

5.1 Dev Environment (versione latest)<\/h3>\n

docker-compose -f docker-compose.dev.yml up
\n# Dove docker-compose.dev.yml contiene:
\n# image: langflow\/langflow:latest
\n# Fate test ogni settimana<\/code><\/p>\n

5.2 Staging Environment (versione N-1 verificata)<\/h3>\n

# Mantenete una versione stabile verificata per una settimana in staging
\ndocker-compose -f docker-compose.staging.yml up
\n# image: langflow\/langflow:1.9.0 # versione stabile verificata<\/p>\n

# Runnable completo con dati reali (anonimizzati)
\n# Load tests per verificare performance
\nab -n 1000 -c 10 https:\/\/langflow-staging.azienda.it\/api\/v1\/flows<\/code><\/p>\n

5.3 Production Environment (versione locked con deliberate update window)<\/h3>\n

docker-compose -f docker-compose.prod.yml up
\n# image: langflow\/langflow:1.9.0@sha256:... # Pin on digest per immutability<\/p>\n

# Update policy:
\n# - Critical patches (CVE CVSS >= 9.0): 48-72 ore
\n# - High (CVSS 7.0-8.9): 2 settimane
\n# - Medium: 1 mese
\n# - Low: con prossima major release<\/p>\n

echo \"Prossimo aggiornamento critico pianificato:\"
\necho \"Data: marted\u00ec 24 settembre 2026 02:00 UTC\"
\necho \"Finestra: 1 ora\"
\necho \"Rollback plan: pre-patch snapshot disponibile\"<\/code><\/p>\n

Step 6: Runtime Detection e Monitoring<\/h2>\n

Le patch e la segmentazione sono statiche. Per rilevare exploit in real-time, ho configurato monitoring runtime:<\/p>\n

6.1 Falco Runtime Security Monitoring<\/h3>\n

# Installate Falco
\ncurl -s https:\/\/falco.org\/repo\/falcosecurity-3672BA8F.asc | apt-key add -
\napt-add-repository \"deb https:\/\/download.falco.org\/packages\/deb stable main\"
\napt-get install falco<\/p>\n

# Regola custom per rilevare shell-from-web-process
\ncat > \/etc\/falco\/rules.d\/langflow-rce.yaml <
\n spawned_process and
\n parent_process_name = \"python\" and
\n container.name contains \"langflow\" and
\n (process_name = \"bash\" or process_name = \"sh\" or process_name = \"nc\")
\n output: >
\n ALERT: Possible RCE in Langflow
\n parent=%parent.name container=%container.name
\n process=%process.name cmdline=%process.cmdline
\n priority: CRITICAL
\n tags: [langflow, rce, injection]
\nEOF<\/p>\n

# Avviate Falco
\nsudo systemctl start falco
\nsudo journalctl -u falco -f<\/code><\/p>\n

6.2 API Endpoint Monitoring<\/h3>\n

#!\/bin\/bash
\n# monitor_langflow_endpoints.sh
\n# Monitorate accessi all'endpoint vulnerabile<\/p>\n

while true; do
\n # Contate richieste a build_public_tmp nell'ultima ora
\n COUNT=$(grep \"build_public_tmp\" \/var\/log\/nginx\/langflow-access.log |
\n grep \"$(date +%d\/%b\/%Y)\" | wc -l)<\/p>\n

if [ $COUNT -gt 5 ]; then
\n # Inviate alert
\n curl -X POST https:\/\/alerts.azienda.it\/webhook
\n -d \"Unusual build_public_tmp requests: $COUNT in last hour\"
\n echo \"ALERT: High volume to vulnerable endpoint\"
\n fi<\/p>\n

sleep 300 # check ogni 5 minuti
\ndone<\/code><\/p>\n

FAQ<\/h2>\n

Abbiamo Langflow 1.8.1 esposto a Internet: quanto siamo in pericolo?<\/h3>\n

Siete in pericolo critico<\/strong>. Nel corso di 48 ore seguenti la pubblicazione dell’advisory, sono stati registrati eventi di exploit CVE-2026-33017 da 6 indirizzi IP unici nel honeypot Sysdig, con i primi tentativi provenienti da infrastruttura di scanning automatizzato<\/cite>. La mia raccomandazione: fermate immediatamente l’istanza se non \u00e8 mission-critical, applicate il patch a 1.9.0, ruotate tutte le credenziali e controllate i log.<\/p>\n

CVE-2026-33017 \u00e8 stato risolto completamente nella versione 1.8.2?<\/h3>\n

No. Il team di JFrog Security Research ha confermato che Langflow versione 1.8.2, ampiamente riportata come patchata per CVE-2026-33017, rimane vulnerabile a remote code execution, creando un gap pericoloso tra la sicurezza percepita e quella reale<\/cite>. Dovete aggiornare a 1.9.0 o superiore e verificare la fix con test reali prima di considerare il sistema sicuro.<\/p>\n

Come possiamo proteggere Langflow se la versione 1.9.0 non \u00e8 ancora stable nel nostro stack?<\/h3>\n

La protezione in-depth<\/em> \u00e8 la soluzione: disabilitate il parametro AUTO_LOGIN, nascondete Langflow dietro un reverse proxy con autenticazione forte (OAuth2, SAML), implementate network segmentation per raggiungere solo da IP aziendali, disabilitate l’endpoint \/api\/v1\/build_public_tmp\/ se non necessario, e abilitate monitoring runtime con Falco. Nessuna di queste misure sostituisce il patching, ma insieme riducono drasticamente il rischio fino a quando non potete aggiornare.<\/p>\n

Langflow \u00e8 embedded in un contenitore Kubernetes production: qual \u00e8 la procedura di aggiornamento con zero downtime?<\/h3>\n

Usate rolling updates con health check: specificate il nuovo digest immagine nella spec del Deployment, configurate readiness probe e liveness probe, e Kubernetes far\u00e0 rolling update automaticamente. Se qualcosa va storto, fate rollback immediato: kubectl rollout undo deployment\/langflow<\/code><\/p>\n

Abbiamo centinaia di flow con credenziali hardcoded: come li migriamo a secret management?<\/h3>\n

Implementate secure library e code repository management per prevenire supply chain attack targeting LLM applications, usando strumenti di software composition analysis per scansionare dipendenze da vulnerabilit\u00e0 note, e mantenendo repository code sicuri con access control, meccanismi autenticazione e multi-factor authentication per tutti gli account developer<\/cite>. Nel mio ambiente, ho usato HashiCorp Vault per centralizzare i secret e ho creato custom component Langflow che legge da Vault invece che da file.<\/p>\n

Conclusione<\/h2>\n

Le vulnerabilit\u00e0 qui sono ordinarie \u2013 quello che \u00e8 cambiato \u00e8 che abbiamo lanciato migliaia di ambienti Python execution raggiungibili da Internet pieni di chiavi API e non li abbiamo mai messi nel security program che governa tutto il resto di quello che eseguiamo<\/cite>. CVE-2026-33017 \u00e8 una lezione cruciale: i framework di orchestrazione LLM sono credential concentrators<\/em> che devono essere protetti come sistemi di gestione accesso critica, non come applicazioni web ordinarie.<\/p>\n

La mia strategia tre-livelli \u2013 patching verificato, network segmentation severa e runtime monitoring \u2013 ha trasformato un asset ad altissimo rischio in un componente protetto. Se state ancora eseguendo Langflow 1.8.1 o 1.8.2, la finestra per agire \u00e8 piccola. Se volete approfondire la sicurezza degli orchestration framework, vi consiglio di leggere anche il mio articolo su Come Proteggere Development Pipeline da Prompt Injection<\/a>, che copre tematiche correlate di injection attack nei sistemi AI, e il mio approfondimento su Agentic AI Orchestration Layer Security<\/a>.<\/p>\n

Condividete nei commenti come state proteggendo i vostri Langflow: quali strategie di patching usate? Avete incontrato CVE-2026-33017 in produzione?<\/p>\n","protected":false},"excerpt":{"rendered":"

CVE-2026-33017 \u00e8 un’RCE unauthenticated in Langflow che compromette completamente istanze esposte. Vi mostro come patchare realmente (1.9.0 verificato), proteggere con network segmentation e ruotare credenziali.<\/p>\n","protected":false},"author":1,"featured_media":4317,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"Proteggere Langflow CVE-2026-33017 RCE | LLM Security","_seopress_titles_desc":"CVE-2026-33017 Langflow RCE: procedura patch 1.9.0, network hardening, credential rotation. Proteggi orchestration framework AI da exploitation unauthenticated.","_seopress_robots_index":"","footnotes":""},"categories":[7],"tags":[1307,1305,1304,1049,1306],"class_list":["post-4316","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-android","tag-ai-framework-hardening","tag-cve-2026-33017","tag-langflow","tag-llm-security","tag-rce"],"_links":{"self":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/4316","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/comments?post=4316"}],"version-history":[{"count":0,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/posts\/4316\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media\/4317"}],"wp:attachment":[{"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/media?parent=4316"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/categories?post=4316"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darioiannascoli.it\/blog\/wp-json\/wp\/v2\/tags?post=4316"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}