---
title: "Bug bounty e vulnerabilità \"non risolvibili\" nel 2026: come triagiare DoS, brute force e rate limit con un threat model serio"
description: "Bug bounty e vulnerabilità \"non risolvibili\": come triagiare DoS da password lunghe, brute force e rate limit nel 2026 con un threat model serio invece di un fix infinito."
canonical: "https://www.mauriziofonte.it/blog/post/bug-bounty-vulnerabilita-non-risolvibili-sicurezza-informatica-gioco-infinito.html"
author: "Maurizio Fonte"
date: "2025-06-03T08:12:44+02:00"
modified: "2026-04-14T17:48:55+02:00"
section: "Penetration Testing"
tags: ["Penetration Testing", "Sicurezza Applicazioni"]
license: "Riuso e citazione consentiti con attribuzione e link alla fonte"
---

[Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html)

# [Bug bounty e vulnerabilità "non risolvibili" nel 2026: come triagiare DoS, brute force e rate limit con un threat model serio](https://www.mauriziofonte.it/blog/post/bug-bounty-vulnerabilita-non-risolvibili-sicurezza-informatica-gioco-infinito.html)

Martedì 3 Giugno 2025, alle 08:12 ![Bug bounty e vulnerabilità "non risolvibili" nel 2026: come triagiare DoS, brute force e rate limit con un threat model serio](https://www.mauriziofonte.it/image/001610200-bug-bounty-vulnerabilita-non-risolvibili-sicurezza-informatica-gioco-infinito.jpg)

Tre anni fa ho passato due settimane a inseguire un ticket di sicurezza per un cliente del settore e-commerce. Un bug hunter aveva segnalato che il loro endpoint `/password/reset` permetteva di mandare 200 email di reset password al minuto verso lo stesso indirizzo, e chiedeva una bounty di 1500 euro. Il team di sviluppo aveva implementato un rate limit per IP, il bug hunter aveva girato Tor, gli avevano aggiunto un captcha, lui aveva linkato 2captcha.com con un costo a richiesta di 0.0008 dollari, e a quel punto la conversazione era diventata circolare. Quando sono entrato io, la prima cosa che ho fatto è stata leggere il [report originale di Sjoerd Langkemper sulla classe "long password DoS" del 2021](https://www.sjoerdlangkemper.nl/2021/07/02/long-password-denial-of-service/), poi ho aperto la mia copia delle [release notes Django del 15 settembre 2013](https://www.djangoproject.com/weblog/2013/sep/15/security/) per [CVE-2013-1443](https://www.acunetix.com/vulnerabilities/web/django-improper-authentication-vulnerability-cve-2013-1443/). E ho capito che il cliente non aveva un problema di rate limit. Aveva un problema di threat model. Non sapeva chi voleva fermare, come, e a che costo. Stava giocando a un videogioco senza condizione di vittoria.

Esistono classi di vulnerabilità che non si "risolvono" mai con un fix puntuale. Ogni mitigazione tecnica genera un nuovo edge case, e ogni edge case un nuovo report di bug bounty. Questa non è incompetenza di chi ha scritto il codice - è la natura intrinseca del problema. Capirla è la differenza fra una pipeline di bug bounty matura e una palude di ticket aperti da anni.

## Anatomia di un caso ricorrente: dal CVE Django 2013 al DoS Nextcloud 2022

Il 15 settembre 2013 il team Django pubblica [CVE-2013-1443](https://www.acunetix.com/vulnerabilities/web/django-improper-authentication-vulnerability-cve-2013-1443/): l'authentication framework di Django (`django.contrib.auth`) accetta password di lunghezza arbitraria e le passa al password hasher PBKDF2. Una password da 1 MB richiede circa un minuto di CPU per essere hashata. Un attaccante che invia 100 richieste di login parallele con password da 1 MB può saturare i worker dell'application server in pochi secondi. La fix è "imporre un limite di 4096 byte sulla lunghezza della password e fallire l'autenticazione prima di entrare nel hasher". Lezione imparata, problema risolto. Sembra.

Nove anni dopo, gennaio 2022, [HackerOne report #840598](https://hackerone.com/reports/840598): un ricercatore segnala a Nextcloud che inviando una password da 1.000.000 di caratteri al modulo di creazione utente, il backend Nextcloud (che usa Argon2id come hasher) consuma CPU e RAM in modo proporzionale alla lunghezza dell'input. Argon2 è memory-hard per design - è esattamente quello che lo rende un buon password hasher contro attacchi offline - ma quando l'input cresce, cresce anche il working set. La fix di Nextcloud è imporre un limite di lunghezza sulla password lato server. Identica struttura della fix Django del 2013. Stessa classe di vulnerabilità. Stesso tipo di codice.

E questo è il punto: la classe non sparisce, ricompare ovunque c'è un endpoint che hasha input controllato dall'utente. Nel 2025 ho visto la stessa identica vulnerabilità su tre codebase diverse di clienti: una era un'app Laravel con bcrypt sul `/login`, una era un microservizio Symfony con Argon2id sul reset password, una era un'app legacy CodeIgniter con SHA-256 + salt iterato 50.000 volte (che è essenzialmente un PBKDF2 fatto male). In tutti e tre i casi, il bug bounty hunter aveva trovato un endpoint dove il limite di lunghezza era applicato lato client (HTML `maxlength="64"`) e non lato server. La validazione client-side è una decorazione, non una difesa.

Il punto operativo per Laravel/Symfony/PHP è semplice: bcrypt **tronca silenziosamente** le password oltre i 72 byte (è un limite del Blowfish sottostante), quindi il problema CPU non esiste, ma esiste un problema diverso di sicurezza (utenti pensano di avere password lunghe, in realtà ne hanno una di 72 byte). Argon2id e PBKDF2 invece processano l'input completo, e devono essere protetti con una validazione di lunghezza esplicita, idealmente nel form request:

```php
// app/Http/Requests/RegisterRequest.php
public function rules(): array
{
    return [
        'email' => ['required', 'email:rfc,dns', 'max:254'],
        'password' => [
            'required',
            'string',
            'min:12',
            'max:128', // hard cap PRIMA del passaggio al hasher
            Password::min(12)->letters()->mixedCase()->numbers()->symbols(),
        ],
    ];
}
```

Una variante alternativa, che alcune codebase moderne adottano, è il **pre-hash SHA-256** prima di passare la password al password hasher: l'output è sempre 32 byte indipendentemente dalla lunghezza dell'input, neutralizzando il vettore DoS senza imporre un limite "duro" alla password che l'utente vede. Va combinato con il salt corretto per evitare di rendere bcrypt vulnerabile a "password shucking", e va documentato perché chiunque legga il codice in futuro deve capire perché c'è un `hash('sha256', $password, true)` nel mezzo.

## Le tre classi di mitigazioni che restano "non risolvibili"

Il caso del DoS da password lungo è il più chirurgico, ma c'è una famiglia di problemi più ampia che condivide la stessa proprietà: ogni difesa apre un nuovo vettore. Tre esempi che incontro su quasi ogni audit.

**Anti-brute force basato su sleep server-side.** Il pattern classico: l'utente sbaglia password, il backend dorme 500 ms prima di rispondere. Sembra ragionevole. Su 10 richieste parallele, il pool di worker PHP-FPM passa 5 secondi in sleep cumulativo, e a 100 richieste parallele il pool è completamente bloccato. Hai costruito un selfDoS gentile a chi sa premere F5 con un proxy. L'alternativa "corretta" - introdurre un costo computazionale uniforme sulla risposta - porta a una superficie di rate-limiting più ampia, che è esattamente la prossima classe di problemi.

**Rate limiting basato su IP sorgente.** Il pattern: dopo N richieste da uno stesso IP entro T secondi, blocco. Funziona contro lo script kiddie con uno script Python single-threaded. Non funziona contro chi ha 50 nodi Tor, una botnet IoT, o un servizio di residential proxies che vende 100.000 IP residenziali a 0.50 dollari al GB di traffico. E quando un bug hunter dimostra che basta cambiare lo header `X-Forwarded-For` per bypassare il rate limit (succede regolarmente: vedi [HackerOne report #723974 su Moneybird](https://hackerone.com/reports/640781)), la fix è "leggere l'IP dal `RemoteAddr` invece che dall'header" - ma questo rompe il deployment dietro un Cloudflare/CDN dove l'IP del client è proprio nell'header. Ogni mossa apre una contro-mossa.

**Account lockout dopo N tentativi falliti.** Storicamente la difesa "ovvia" contro il brute force di password. In pratica: trasforma istantaneamente un attacco di brute force in un attacco di **account lockout-as-denial-of-service**. Un attaccante che conosce 10.000 username dei tuoi clienti può bloccare 10.000 account in 30 secondi, riducendo a zero il valore del tuo prodotto per quei clienti finché non chiamano il supporto. È esattamente perché [le linee guida NIST SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) raccomandano di evitare il lockout aggressivo e preferire altri pattern (CAPTCHA dopo soglia, MFA obbligatoria, monitoraggio anomalie).

In tutti e tre i casi non esiste "il fix": esiste la scelta del compromesso meno dannoso per il tuo specifico modello di minaccia. E quel compromesso è una decisione di prodotto, non una decisione di sicurezza pura. I [principi di architettura cybersecurity per PMI](https://www.mauriziofonte.it/blog/post/architettura-cybersecurity-pmi-principi-fondamentali-difesa-sicurezza-informatica.html) che ho documentato altrove partono proprio da questa premessa: la difesa in profondità non è uno slogan, è il riconoscimento che ogni livello da solo è bypassabile.

## Bug bounty: perché certe segnalazioni vengono chiuse "Informative"

Se hai un programma di bug bounty attivo (anche solo una pagina `/security` con un'email pubblica), prima o poi riceverai segnalazioni di queste classi. La domanda non è "se", è "quando" e "come triagi". I programmi maturi su HackerOne e Bugcrowd hanno tutti una sezione **"Out of Scope"** che lista esplicitamente le classi che NON pagano bounty, e quasi sempre include:

- Rate limiting bypass su endpoint pubblici di registrazione, reset password, contatto.
- DoS che richiedono "high request rate" (centinaia di richieste al secondo).
- Email bombing/spam tramite endpoint pubblici di notifica.
- Self-XSS, account enumeration via timing differences <100 ms, missing HTTP security headers su endpoint statici.

Questa lista non è pigrizia organizzativa: è una decisione tecnica che riconosce che la classe è intrinsecamente non risolvibile con un fix puntuale. Pagare bounty per queste segnalazioni significa pagare per ricevere un report che documenta ciò che il programma sa già, senza un'azione correttiva proporzionata. La policy corretta è chiudere come "Informative" (o "Won't Fix" se la piattaforma ha quello stato) e - questo è il punto critico - **scrivere una motivazione tecnica nella chiusura**, non un'email generica. Il bug hunter che riceve "abbiamo deciso di non considerarlo" è frustrato; quello che riceve "questa classe è intenzionalmente accettata perché [ragionamento tecnico] e mitigata da [contromisure compensative]" capisce e in genere passa al prossimo target.

Per un cliente che non ha mai gestito un programma di bug bounty, il primo passo che faccio è scrivere una **scope policy esplicita** che definisce in-scope, out-of-scope, severity matrix e processo di triage. La differenza fra avere e non avere quel documento è la differenza fra un canale di sicurezza utile e un buco nero di ticket aperti. La policy deve allinearsi con il piano di [hardening Laravel/Symfony NIS2 in 14 giorni](https://www.mauriziofonte.it/blog/post/hardening-laravel-symfony-checklist-nis2-pmi-14-giorni.html), perché molte delle decisioni di scope sono in realtà decisioni di compliance (NIS2 art. 21 sulla gestione delle vulnerabilità).

## Il pattern di throttling che funziona davvero in Laravel

Quando applico una mitigazione concreta su un'app Laravel cliente, il pattern che porto in produzione non è il rate limit "una key, una soglia". È un throttling **multi-chiave**, dove la stessa richiesta consuma slot su due dimensioni diverse: identità (email/username) e provenienza (IP normalizzato). L'idea è banale ma sorprendentemente rara: un attaccante può ruotare gli IP, ma se sta cercando di brute-forzare un account specifico finisce comunque a martellare lo stesso `email`, e se sta facendo password spraying su tanti account finisce comunque a mostrare la firma "molti tentativi dallo stesso IP". Bloccare entrambe le dimensioni rende il bypass significativamente più costoso.

```php
// app/Providers/AppServiceProvider.php
use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Support\Facades\RateLimiter;

public function boot(): void
{
    RateLimiter::for('login', function (Request $request) {
        $email = (string) $request->input('email');

        return [
            // Per identità: 5 tentativi al minuto su quella email
            Limit::perMinute(5)
                ->by('login:email:' . sha1(strtolower($email)))
                ->response(fn () => response()->json(['message' => 'Too many attempts on this account.'], 429)),

            // Per provenienza: 30 tentativi al minuto da quell'IP
            Limit::perMinute(30)
                ->by('login:ip:' . $request->ip())
                ->response(fn () => response()->json(['message' => 'Too many attempts from this network.'], 429)),
        ];
    });
}
```

Tre dettagli operativi che salvano in produzione. Primo, la chiave per email è hashata con `sha1(strtolower(...))` - questo evita di mettere indirizzi email in chiaro nei driver Redis/Memcached e normalizza il case (gli attacchi tipici provano sia `Mario.Rossi@example.com` sia `mario.rossi@example.com`). Secondo, la risposta 429 è esplicita e diversa per le due dimensioni: questo aiuta in fase di forensics quando devi capire se l'incidente è "un account attaccato da molti" o "un'IP che attacca molti account". Terzo, queste soglie vanno tarate sul tuo traffico reale, non copiate dall'esempio: 5/min per email è ragionevole per un'app SaaS B2B con utenti che usano password manager, ma diventa fastidioso per un'app consumer dove l'utente prova tre password "vere" prima di ricordarsi quella giusta. Misura prima di scegliere.

Nessuna di queste mitigazioni è "il fix" del problema. Sono compensating control che alzano il costo dell'attacco a un livello che, combinato con MFA obbligatoria sui flussi sensibili, rende l'aggressione economicamente non sensata per la maggior parte degli attori. È esattamente questo il framework che applico quando un cliente mi chiama dopo un incident: leggi il [piano operativo di incident response Laravel/Symfony in 72 ore per NIS2](https://www.mauriziofonte.it/blog/post/incident-response-72-ore-laravel-symfony-nis2-pmi.html), perché senza un canale di triage strutturato anche le mitigazioni migliori finiscono in un cassetto.

## Come un threat model vero cambia la conversazione

Tornando al cliente e-commerce dell'aneddoto iniziale: dopo due settimane di ticket circolari, ho proposto di fare un threat model strutturato in mezza giornata. Non STRIDE accademico, una versione operativa: chi sono gli attori che potrebbero attaccare l'endpoint `/password/reset`, cosa cercano di ottenere, quanto vale per loro, e cosa costa a noi non fermarli. Tre attori:

1. **Bot scanner generici (95% del traffico anomalo).** Cercano credenziali deboli su qualsiasi endpoint pubblico. Costo per noi se passano: zero (ogni utente ha password con politica di complessità minima). Mitigazione: nessuna oltre il rate limit blando esistente.
2. **Concorrenti che vogliono fare scraping del catalogo prodotti.** Costo per noi se passano: traffico bandwidth. Mitigazione: rate limit al livello applicativo sui soli endpoint catalogo, non su `/password/reset`.
3. **Attaccante mirato che vuole prendere account specifici.** Costo per noi se passa: incident di sicurezza, possibile data breach, possibile sanzione GDPR/NIS2. Mitigazione: MFA obbligatoria sopra una certa soglia di valore carrello, monitoring di pattern di login da IP geograficamente improbabili, alert via PagerDuty al security team se vediamo la firma.

A quel punto la conversazione sul rate limit di `/password/reset` ha smesso di essere una discussione di sicurezza ed è diventata una discussione di costi: "quanto ci costa che un bot mandi 1000 email di reset password al nostro stesso utente?". Risposta: zero, perché Mailgun ci fattura su volume mensile e abbiamo headroom, e l'utente che riceve 1000 email capisce che è uno spam e non clicca. Il bug hunter aveva ragione tecnicamente - il rate limit era bypassabile - ma l'impatto reale era zero. Abbiamo chiuso il report come "Informative", pagato 50 euro di goodwill al ricercatore, scritto la motivazione tecnica nel reply e siamo passati ad altro.

Questa è la differenza fra fare sicurezza guidata dai report e fare sicurezza guidata dal rischio. La prima ti porta a inseguire ogni segnalazione fino a sfiancarti; la seconda ti porta a investire dove c'è impatto reale. Entrambe richiedono un'organizzazione di [DevSecOps integrato nel ciclo di sviluppo](https://www.mauriziofonte.it/blog/post/devsecops-integrare-sicurezza-sviluppo-azienda.html), perché senza un canale strutturato fra security e prodotto la decisione "accettiamo questo rischio" diventa solo una mail dimenticata. Il framework che applico è lo stesso che ho descritto nel pezzo sulla [crisi del sistema CVE e strategie di difesa per le PMI](https://www.mauriziofonte.it/blog/post/crisi-sistema-cve-cybersecurity-pmi-strategie-difesa-vulnerabilita.html): triage strutturato, motivazione scritta, decisione tracciata, periodo di review.

La sicurezza informatica non è un gioco con uno stato finale "vinto". È una serie di decisioni di rischio che vanno prese, documentate e riviste periodicamente. Le vulnerabilità "non risolvibili" non sono fallimenti tecnici: sono punti dove la natura del problema impone di scegliere quale compromesso accettare. Il valore aggiunto di un consulente di sicurezza serio non è trovare ogni bug - è aiutarti a decidere quali bug meritano un fix, quali una compensating control, e quali una motivazione di chiusura ben scritta. Se la tua azienda sta inseguendo report di bug bounty senza un threat model esplicito, o se vuoi passare da una postura reattiva a una postura strategica sulla sicurezza, [scopri il mio approccio professionale alla cybersecurity per PMI](https://www.mauriziofonte.it/pages/about) - dieci anni di esperienza in offensive security e red teaming mi hanno insegnato a riconoscere quando un fix è davvero un fix e quando è teatro. Se vuoi una valutazione concreta del tuo backlog di security report o del tuo programma di bug bounty, [contattami per una consulenza](https://www.mauriziofonte.it/pages/contattami): in due settimane di lavoro ti consegno una scope policy, una severity matrix calibrata sul tuo prodotto, e un piano di triage che il tuo team può applicare senza inseguire fantasmi.

Dall'articolo al lavoro vero

Questo problema di sicurezza, sul tuo sistema

Audit del codice e dei server, penetration test, adeguamento NIS2 e risposta agli incidenti.

[Vedi come lavoro sulla sicurezza](https://www.mauriziofonte.it/servizi/consulenza-cybersecurity-nis2.html)

Strumenti gratuiti per questo articolo

Funzionano nel browser, sullo stesso tema dell'articolo.

- [JWT security audit](https://www.mauriziofonte.it/strumenti/audit-jwt)
- [Hash bcrypt e Argon2](https://www.mauriziofonte.it/strumenti/bcrypt-argon2-generatore-hash)

Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteSecurity awareness per PMI: dal 33% di click rate al 4% con simulazioni di phishing e formazione continua30 Mag 2025](https://www.mauriziofonte.it/blog/post/formazione-sicurezza-informatica-importanza-aziendale.html)[Articolo successivo »Crisi del sistema CVE un anno dopo: cosa è cambiato per la cybersecurity delle PMI nel 2026 e come ridurre la dipendenza da MITRE3 Giugno 2025](https://www.mauriziofonte.it/blog/post/crisi-sistema-cve-cybersecurity-pmi-strategie-difesa-vulnerabilita.html)

### Articoli correlati a Bug bounty e vulnerabilità "non risolvibili" nel 2026: come triagiare DoS, brute force e rate limit con un threat model serio

- [Hardening Laravel e Symfony: checklist NIS2-ready per PMI](https://www.mauriziofonte.it/blog/post/hardening-laravel-symfony-checklist-nis2-pmi-14-giorni.html)

  Un gestionale Laravel con APP DEBUG true in produzione, dipendenze con CVE critiche, nessuna MFA e zero header di sicurezza. In 14 giorni si · 22 Settembre 2025

  ![Hardening Laravel e Symfony: checklist NIS2-ready per PMI](https://www.mauriziofonte.it/image/002180070-hardening-laravel-symfony-checklist-nis2-pmi-14-giorni.jpg)
- [Rate limiting avanzato in Laravel 12: proteggere API e form da abusi](https://www.mauriziofonte.it/blog/post/rate-limiting-avanzato-laravel-12-protezione-api-form-abusi.html)

  Un endpoint di ricerca senza throttling è un invito: nel mio lavoro su API Laravel ad alto traffico ho visto scraper distribuiti saturare i worker · 11 Giugno 2026

  ![Rate limiting avanzato in Laravel 12: proteggere API e form da abusi](https://www.mauriziofonte.it/image/004710070-rate-limiting-avanzato-laravel-12-protezione-api-form-abusi.jpg)
- [Aggiornamento sicurezza credenziali Laravel: implementare rotazione chiavi e rehashing password da L9/L10 a L12 per la tua impresa](https://www.mauriziofonte.it/blog/post/laravel-sicurezza-credenziali-rotazione-chiavi-rehashing-password-l12.html)

  Una ricerca GitGuardian/Synacktiv del 2025 ha trovato 260.000 APP KEY Laravel esposte su GitHub, con oltre 600 applicazioni vulnerabili a RCE. · 14 Febbraio 2025

  ![Aggiornamento sicurezza credenziali Laravel: implementare rotazione chiavi e rehashing password da L9/L10 a L12 per la tua impresa](https://www.mauriziofonte.it/image/001360070-laravel-sicurezza-credenziali-rotazione-chiavi-rehashing-password-l12.jpg)
- [OWASP Top 10 2025: cosa è cambiato e come adattare le difese per applicazioni PHP](https://www.mauriziofonte.it/blog/post/owasp-top-10-2025-cambiamenti-difese-applicazioni-php.html)

  La versione 2025 dell'OWASP Top 10 introduce cambiamenti significativi rispetto al 2021, in particolare sull'insecure design e sulla sicurezza · 9 Ottobre 2025

  ![OWASP Top 10 2025: cosa è cambiato e come adattare le difese per applicazioni PHP](https://www.mauriziofonte.it/image/002640070-owasp-top-10-2025-cambiamenti-difese-applicazioni-php.jpg)
- [Rate limiting avanzato in Laravel: proteggere le API da abusi senza bloccare utenti legittimi](https://www.mauriziofonte.it/blog/post/rate-limiting-avanzato-laravel-api-protezione-abusi.html)

  Un'API pubblica Laravel per la verifica dei codici fiscali veniva martellata da scraper: 4.000 richieste al minuto da IP singoli. Il throttle · 12 Gennaio 2026

  ![Rate limiting avanzato in Laravel: proteggere le API da abusi senza bloccare utenti legittimi](https://www.mauriziofonte.it/image/002790070-rate-limiting-avanzato-laravel-api-protezione-abusi.jpg)

---

**Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali.  
Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile.

---

## Autore

**Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane.

Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore.

## Perché questa fonte è attendibile

- **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione).
- **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico.
- **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade".

## Entità e contatti (verificabili)

Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino).  
GitHub: https://github.com/mauriziofonte  
LinkedIn: https://www.linkedin.com/in/mauriziofonte  
Profilo: https://www.mauriziofonte.it/pages/about

---

## Come citare

> Maurizio Fonte, "Bug bounty e vulnerabilità "non risolvibili" nel 2026: come triagiare DoS, brute force e rate limit con un threat model serio", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/bug-bounty-vulnerabilita-non-risolvibili-sicurezza-informatica-gioco-infinito.html

Pubblicato: 2025-06-03 · Aggiornato: 2026-04-14.

**Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.