Lasciaci i tuoi recapiti e ti invieremo una panoramica dei nostri servizi via email.
Acconsento al trattamento dei miei dati personali per l’invio di comunicazioni di marketing personalizzate, in conformità all’ Informativa sulla privacy,. Confermando l'invio, l'utente accetta di ricevere comunicazioni di marketing
Grazie!

Il modulo è stato inviato con successo.
Ulteriori informazioni sono contenute nella tua casella di posta elettronica.

Dati IA Mobile Finanza Scienze della vita ERP
Innowise logo
Chi siamo
Servizi
Tecnologie
Industrie
I nostri progetti
Flash hire iconAffidati a noi Flash hire iconAffidati a noi
Contattaci Contattateci
IT
Come lavoriamo Gestione della qualità Gestione della sicurezza Responsabilità sociale d'impresa Dirigenza I nostri esperti Blog Consigli degli esperti
Recensioni dei clienti Partner tecnologici Certificazioni Premi Eventi Notizie
Sviluppo software in-house vs outsourcing 2026: pro, contro, costi e modalità di scelta
Leggi l'articolo
Servizi di sviluppo software a ciclo completo
Consulenza informatica e advisory Sviluppo web Sviluppo mobile Sviluppo di software embedded Sviluppo software su misura Sviluppo dell’MVP Sviluppo cloud Sviluppo ERP Supporto mainframe Modernizzazione dei sistemi legacy
 
UI/UX design Design 3D Test del software e QA Test di sicurezza Amministrazione di database DevOps DevSecOps Rete IT staff augmentation Team dedicato
Implementazione di tecnologie avanzate
Big data Gestione dei dati Analisi dei dati Ingegneria dei dati Visualizzazione dei dati Business intelligence Machine learning Intelligenza artificiale Data science Sostenibilità e ESG

Trasformazione digitale Automazione dei processi aziendali Automazione robotica dei processi Cybersecurity Internet of Things (IoT) Blockchain NFT Metaverse AR& VR
Front end
React Angular Vue.js JavaScript
Back end
Java .NET Python PHP Rust C/C++
 
Node.js Unity Ruby Golang Unreal Engine Cobol
Mobile
iOS Android Flutter React Native Xamarin .NET MAUI
 
Swift Kotlin
Cloud
AWS Azure GCP Sharepoint
ERP & CRM
SAP MS Dynamics 365 Odoo Salesforce Creatio
Finanza Banche Commercio Assicurazioni E-commerce Retail
Sanità Farmaceutica Istruzione Telecomunicazioni Media & intrattenimento
Grandi imprese Industria manifatturiera Automobilistico Logistica Trasporto Marketing Pubblicità
Pubblica amministrazione Energia & utility Petrolio e gas Edilizia Immobili Agricoltura Viaggi
I nostri progetti
Banche Finanza Sanità Settore farmaceutico
E-commerce Retail Industria manifatturiera Grandi imprese
Le nostre piattaforme
Sistema di tracciamento dei candidati (ATS) Sistema HRM Sistema di gestione dell'apprendimento (LMS) Sistema di prenotazione degli spazi di lavoro
Sistema operativo finanziario basato sull'intelligenza artificiale unificato per valute tradizionali e criptovalute
Leggi il case study
Assumi sviluppatori dedicati
IT staff augmentation Team dedicati Sviluppatori offshore
Assumi sviluppatori web
Angular React.js Vue.js JavaScript Ruby on Rails Full stack MEAN stack
.NET Java PHP Python Golang Cobol
Assumi sviluppatori mobile
iOS Android Kotlin React Native Swift
Assumi altri ingegneri
IA Cloud AWS Azure DevOps QA
Fintech SAP Odoo Salesforce Shopify UiPath
Dati IA Mobile Finanza Scienze della vita ERP
Innowise logo
Chi siamo
Servizi
Tecnologie
Industrie
I nostri progetti
Flash hire iconAffidati a noi
Contattaci
it Italiano

Seleziona la lingua

Mobile menu arrow iconChi siamo
Chi siamo
Come lavoriamo Gestione della qualità Gestione della sicurezza Responsabilità sociale d'impresa Dirigenza I nostri esperti Blog Consigli degli esperti
Recensioni dei clienti Partner tecnologici Certificazioni Premi Eventi Notizie
Sviluppo software in-house vs outsourcing 2026: pro, contro, costi e modalità di scelta
Leggi l'articolo
Mobile menu arrow iconServizi
Tutti i servizi
Servizi di sviluppo software a ciclo completo
Consulenza informatica e advisory Sviluppo web Sviluppo mobile Sviluppo di software embedded Sviluppo software su misura Sviluppo dell’MVP Sviluppo cloud Sviluppo ERP Supporto mainframe Modernizzazione dei sistemi legacy
UI/UX design Design 3D Test del software e QA Test di sicurezza Amministrazione di database DevOps DevSecOps Rete IT staff augmentation Team dedicato
Implementazione di tecnologie avanzate
Big data Gestione dei dati Analisi dei dati Ingegneria dei dati Visualizzazione dei dati Business intelligence Machine learning Intelligenza artificiale Data science Sostenibilità e ESG
Trasformazione digitale Automazione dei processi aziendali Automazione robotica dei processi Cybersecurity Internet of Things (IoT) Blockchain NFT Metaverse
AR &VR
Mobile menu arrow iconTecnologie
Tutte le tecnologie
Front end
React Angular Vue.js JavaScript
Back end
Java .NET Python PHP Node.js Unity Ruby Golang Rust C/C++ Unreal Engine Cobol
Mobile
iOS Android Flutter React Native Xamarin .NET MAUI Kotlin Swift
Cloud
AWS Azure GCP Sharepoint
ERP & CRM
SAP MS Dynamics 365 Odoo Salesforce Creatio
Mobile menu arrow iconIndustrie
Tutti i settori
Finanza Banche Commercio Assicurazioni E-commerce Retail
Sanità Farmaceutica Istruzione Telecomunicazioni Media & intrattenimento
Grandi imprese Industria manifatturiera Automobilistico Logistica Trasporto Marketing Pubblicità
Pubblica amministrazione Energia & utility Petrolio e gas Edilizia Immobili Agricoltura Viaggi
Mobile menu arrow iconI nostri progetti
I nostri progetti
I nostri progetti
Banche Finanza Sanità Settore farmaceutico
E-commerce Retail Industria manifatturiera Grandi imprese
Le nostre piattaforme
Sistema di tracciamento dei candidati (ATS) Sistema HRM Sistema di gestione dell'apprendimento (LMS) Sistema di prenotazione degli spazi di lavoro
Sistema operativo finanziario basato sull'intelligenza artificiale unificato per valute tradizionali e criptovalute
Leggi il case study
Mobile menu arrow icon Affidati a noi
Affidati a noi
Assumi sviluppatori dedicati
IT staff augmentation Team dedicati Sviluppatori offshore
Assumi sviluppatori web
Angular React.js Vue.js JavaScript Ruby on Rails Full stack MEAN stack .NET Java PHP Python Golang Cobol
Assumi sviluppatori mobile
iOS Android Kotlin React Native Swift
Assumi altri ingegneri
IA Cloud AWS Azure DevOps QA Fintech SAP Odoo Salesforce Shopify UiPath

Lista di controllo per la sicurezza di PHP: 8 passaggi per individuare e correggere le vulnerabilità

5 novembre 2026 19 minuti di lettura
php icon.
Herman Samolazov, Head of Engineering..
Di Herman Samolazov
Responsabile di Engineering
Esperto verificato
Ogni articolo pubblicato su Innowise è redatto da autori con esperienza sul campo. Questi autori conoscono l'argomento non solo a livello teorico, ma apportano anche approfondimenti tratti da progetti reali.
7+ anni di esperienza
Esperto verificato
7+ anni di esperienza
Herman è a capo dei reparti di ingegneria e si occupa di definire i processi, le strutture dei team e gli standard tecnici necessari per la loro crescita. Le sue competenze spaziano dai sistemi backend ad alto carico alla gestione delle consegne, fino alla leadership ingegneristica.
Competenze specialistiche
Sistemi per carichi elevati Architettura software Database
In primo piano su
Medium logo.
Parliamo del tuo progetto

Punti chiave

  • PHP2Shell richiede una correzione urgente. Il 21 ottobre 2026, PHP ha risolto CVE-2026-109618 e CVE-2026-109619. Entrambe sono vulnerabilità critiche di runtime (CVSS v4.0: 9,2) che possono consentire l’esecuzione di codice remoto non autenticato.
  • Verifica le versioni corrette. Le prime versioni corrette sono PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Le distribuzioni Linux potrebbero fornire le stesse correzioni tramite patch backportate.
  • Dare priorità ai runtime PHP esposti. mod_php di Apache presenta il rischio più elevato segnalato, ma anche PHP-FPM e altre configurazioni rivolte al web richiedono attenzione. Gli aggiornamenti dei framework e l’audit di Composer non risolvono la vulnerabilità PHP2Shell.
  • Non limitatevi ad applicare le patch a PHP. Utilizzate la checklist in otto passaggi per esaminare le dipendenze, il codice dell’applicazione, le impostazioni del server e altre vulnerabilità di sicurezza.
  • Verificate la correzione in produzione. Chiedete al vostro team un rapporto che indichi quali build di PHP sono effettivamente in esecuzione, quali carichi di lavoro sono stati aggiornati e se ci sono segni di compromissioni precedenti.
Genera un riassunto con l'IA
Aggiungi alle fonti preferite

Secondo W3Techs, PHP è alla base di circa il 70% dei siti web in cui è noto il linguaggio lato server. Poiché PHP è così diffuso, una vulnerabilità nell’interprete può mettere a rischio molti siti, anche se il loro codice è sicuro.

Il 21 ottobre 2026, il progetto PHP ha rilasciato patch di emergenza per due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, denominate collettivamente PHP2Shell. Entrambe hanno ottenuto un punteggio di 9,2 secondo il CVSS v4.0 e consentono l’esecuzione di codice remoto senza autenticazione. Queste vulnerabilità interessano la memoria interna e la gestione delle richieste di PHP.

Le prime patch sono state rilasciate nelle versioni PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Se il vostro sistema utilizza una delle versioni interessate, aggiornate immediatamente PHP e assicuratevi che il vostro server web stia utilizzando la versione aggiornata. Ma il lavoro non dovrebbe fermarsi qui. Per i team che sviluppano e gestiscono applicazioni PHP, compresi gli specialisti dello sviluppo InnowisePHP specialisti di sviluppo, il rilascio di ottobre rappresenta anche un’occasione per rivedere le dipendenze, il codice delle applicazioni e le impostazioni del server.

In questa guida vi mostrerò otto passaggi per individuare e correggere le vulnerabilità nella vostra configurazione PHP e verificare che le correzioni funzionino in produzione.

Scopri altri servizi che offriamo

Analisi approfondita: in che modo PHP2Shell si differenzia da una normale vulnerabilità CVE legata alle dipendenze

Un pacchetto Composer vulnerabile influisce sul codice utilizzato dalla tua applicazione. PHP2Shell è diverso. Entrambe le vulnerabilità si trovano all'interno dello stesso interprete PHP, e un malintenzionato potrebbe sfruttarle prima di Laravel, Symfony o un altro framework non sia nemmeno avviato. L’aggiornamento dei plugin CMS o delle dipendenze di Composer non applicherà patch a PHP, e composer audit non rileverà queste vulnerabilità di runtime.

Il team di sicurezza di PHP identifica Apache mod_php come la configurazione a più alto rischio per CVE-2026-109618, con un attacco dimostrato che funziona prima dell’esecuzione del codice dell’applicazione. Anche PHP-FPM, CGI e altre configurazioni di server web sono interessate, sebbene le condizioni di sfruttamento differiscano. I ricercatori hanno inoltre dimostrato lo sfruttamento della vulnerabilità CVE-2026-109619 contro PHP-FPM.

Ecco cosa va storto in ciascun caso:

CVECausa principalePerché le squadre dovrebbero interessarsene
CVE-2026-109618Se PHP esaurisce la memoria durante l'elaborazione di una richiesta, alcuni dati interni potrebbero rimanere in uno stato non valido. Quando PHP provvede alla pulizia della richiesta non andata a buon fine, potrebbe utilizzare tali dati.Se PHP esaurisce la memoria durante l'elaborazione di una richiesta, alcuni dati interni potrebbero rimanere in uno stato non valido. Quando PHP provvede alla pulizia della richiesta non andata a buon fine, potrebbe utilizzare tali dati.
CVE-2026-109619Un PHP worker potrebbe mantenere un riferimento a memoria che è stata liberata dopo una richiesta precedente. Quando il worker gestisce un'altra richiesta, potrebbe tentare di utilizzare quel vecchio riferimento.Il problema può persistere tra le richieste gestite dallo stesso worker. Il controllo delle singole richieste dell'applicazione non lo metterà necessariamente in evidenza.

Entrambe le vulnerabilità possono consentire l'esecuzione di codice da remoto senza autenticazione. La correzione riguarda il runtime PHP, non le dipendenze dell’applicazione.

Per una spiegazione tecnica più approfondita, è possibile consultare gli avvisi del progetto PHP relativi a CVE-2026-109618 e CVE-2026-109619.

Da dove provengono le vulnerabilità di sicurezza di PHP?

Come ho già detto, l’aggiornamento di PHP non risolverà il problema di un pacchetto Composer vulnerabile, e una scansione completa delle dipendenze non individuerà eventuali problemi nel codice dell’utente. Quando esamino un'applicazione PHP, prendo in considerazione quattro fonti di rischio per la sicurezza, ciascuna con le proprie potenziali conseguenze.

CategoriaEsempiRischio principale
Runtime PHPVersioni non aggiornate di PHP, vulnerabilità dell'interprete, versioni non supportateGli hacker sfruttano le vulnerabilità presenti nello stesso PHP, indipendentemente dal livello di sicurezza con cui è stata sviluppata l'applicazione
Dipendenze di terze partiPacchetti Composer, plugin CMS, frameworkIl codice di terze parti contenente vulnerabilità espone le applicazioni agli attacchi anche quando il codice proprio è sicuro
Codice dell'applicazioneIniezione SQL, XSS, CSRF, deserializzazione non sicura, controllo degli accessi non correttoEventuali difetti nel codice potrebbero consentire agli hacker di sottrarre dati, compiere azioni non autorizzate o compromettere l'applicazione
Configurazione e infrastrutturaImpostazioni PHP non sicure, file esposti, permessi eccessiviEventuali configurazioni errate potrebbero esporre informazioni sensibili o consentire agli aggressori un accesso più ampio di quanto previsto

Risolvere le vulnerabilità PHP prima che si aggravino

Parla con i nostri esperti

Lista di controllo per la sicurezza di PHP: 8 verifiche fondamentali

Passiamo ora in rassegna gli otto controlli di sicurezza che utilizzerei per un'applicazione PHP esistente. Inizierei con l’ambiente di esecuzione PHP che gestisce le richieste in tempo reale, quindi esaminerei il codice, le dipendenze e la configurazione alla ricerca di problemi che un semplice aggiornamento PHP non è in grado di risolvere.

Verifica la versione di PHP e le patch di sicurezza

Innanzitutto, identifica quali runtime PHP utilizzano le tue applicazioni: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP o LiteSpeed. Includere pool FPM separati, container, installazioni CLI, queue worker e processi pianificati.

Non fare affidamento esclusivamente su php -v o php –ini. php -v mostra la versione CLI, mentre php –ini ne mostra la configurazione. Nessuno dei due conferma quale PHP runtime stia gestendo le richieste web.

Confronta il runtime attivo e la sua configurazione con l"avviso ufficiale PHP, comprese le versioni interessate e le condizioni di vulnerabilità. mod_php di Apache presenta la vulnerabilità PHP2Shell più grave, con un percorso di exploit già prima dell’esecuzione del codice dell’applicazione. La vulnerabilità di PHP-FPM dipende dalla configurazione e dai percorsi di esecuzione. Anche le altre SAPI necessitano di una valutazione, poiché la SAPI da sola non è sufficiente a stabilire se una distribuzione sia sicura.

Le prime versioni upstream contenenti entrambe le correzioni sono state:

Ramo PHPPrima versione stabile
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Queste versioni sono elencate nelle avvisi PHP relativi a CVE-2026-109618 e CVE-2026-109619. Verificare la disponibilità di versioni di sicurezza più recenti prima di procedere all'aggiornamento.

Verifica delle patch PHP su Linux e nei container

Verifica il runtime attivo. Controlla la configurazione del tuo server web per identificare il modulo PHP, il pool FPM o la SAPI incorporata che gestisce le richieste. Verifica la versione utilizzando strumenti diagnostici ad accesso limitato e, successivamente, rimuovi eventuali endpoint temporanei. Non rendere mai pubblici phpinfo() o un endpoint relativo alla versione.

Verifica i pacchetti installati. Su Ubuntu con PHP 8.3, questi comandi in sola lettura mostrano i pacchetti installati e le versioni disponibili:

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Adattare i nomi dei pacchetti in base al proprio ramo PHP e confrontare le versioni installate con le note di sicurezza del fornitore o il log delle modifiche del pacchetto. I fornitori di Linux potrebbero effettuare il backport delle correzioni nelle versioni precedenti di PHP. Ad esempio, Ubuntu elenca queste build corrette:

  • Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04: 8.1.2-1ubuntu2.28

Entrambe contengono le correzioni pertinenti nonostante i numeri di versione inferiori. Consultare l"avviso di sicurezza di Ubuntu.

Applicare le patch e ridistribuire. Installare i pacchetti con le patch. Per i container, registrare il digest dell’immagine in esecuzione, aggiornare le immagini di base PHP vulnerabili, ricompilare e ridistribuire i carichi di lavoro interessati, inclusi i worker di coda.

Verificare il risultato. Riavviare o sostituire i PHP worker interessati e confermare che i processi e i container in esecuzione utilizzino build aggiornate o backport verificati dal fornitore. Registrare le versioni dei pacchetti, i digest delle immagini in esecuzione, i dettagli del riavvio e i risultati della verifica.

PHP 8.1 e versioni precedenti non sono più supportate a monte, sebbene alcuni fornitori continuino a fornire backport di sicurezza. Verificare se la build installata sia coperta e, in caso contrario, effettuare l’aggiornamento. Il supporto di sicurezza per PHP 8.2 termina il 31 dicembre 2026, quindi abbina qualsiasi patch a breve termine a un piano di aggiornamento. È possibile trovare la cronologia completa del supporto nel calendario di supporto di PHP.

Verifica delle dipendenze e dei framework

Inizia con composer.lock. Questo file registra le versioni dei pacchetti da cui dipende la tua applicazione, comprese quelle installate indirettamente tramite altri pacchetti. Esegui questi due comandi:

composer audit --locked
composer outdated

composer audit --locked verifica le versioni bloccate alla luce delle note di sicurezza note e può segnalare i pacchetti abbandonati. composer outdated mostra quali aggiornamenti sono disponibili, ma un pacchetto obsoleto non è necessariamente vulnerabile. Controlla anche gli avvisi relativi a Laravel o Symfony, specialmente se la versione del tuo framework non è più supportata.

Confronta i pacchetti distribuiti in produzione con le versioni presenti nel file lock sottoposto a verifica. Conserva i risultati della verifica e l’inventario dei pacchetti installati insieme ai tuoi registri di rilascio.

Se trovi pacchetti vulnerabili, aggiorna a versioni patchate compatibili e testa le funzionalità interessate. Sostituisci le librerie che non ricevono più correzioni di sicurezza. Se problemi di compatibilità impediscono l’aggiornamento del framework, documentali insieme al lavoro di migrazione necessario. Non trascurare i plugin CMS o le librerie installate al di fuori di Composer.

Un audit di Composer senza anomalie non garantisce che PHP2Shell sia stato risolto. L’audit verifica i pacchetti Composer, mentre PHP2Shell richiede una verifica separata dell’interprete PHP e delle relative patch. Per valutare l’applicazione stessa, utilizzare SAST per analizzare il codice sorgente e DAST per testare l’applicazione in esecuzione.

Riepilogo PHP e configurazioni del server

Verifica le impostazioni PHP effettivamente utilizzate dal tuo server web, comprese le sostituzioni del pool PHP-FPM e le estensioni caricate. Ricorda che php --ini mostra la configurazione CLI, che potrebbe differire da quella dell'applicazione in produzione.

Per l'ambiente di produzione, inizia con:

display_errors = Off
log_errors = On

Conserva i log al di fuori delle directory accessibili pubblicamente e limitane l’accesso. Rimuovi le pagine pubbliche phpinfo() e gli endpoint di debug, e verifica expose_php, le estensioni non necessarie e i permessi del filesystem.

La disattivazione di display_errors riduce la divulgazione di informazioni, ma non mitiga la vulnerabilità CVE-2026-109619. Il percorso di codice vulnerabile potrebbe essere eseguito prima che PHP gestisca il messaggio di errore.

Misure temporanee in caso di ritardo nell’applicazione della patch a PHP

Se l’applicazione della patch deve attendere, seguire le indicazioni riportate nell"avviso ufficiale PHP relativo alla propria configurazione.

  • CVE-2026-109619: Disattiva session.upload_progress.enabled e, su PHP 8.5, imposta fatal_error_backtraces=0. Applicare queste impostazioni prima dell’elaborazione delle richieste tramite la configurazione del server o del pool, quindi riavviare i worker interessati. Potrebbero sussistere altre vie di exploit.

  • CVE-2026-109618: Imposta memory_limit=-1 a livello di server o di pool e riavvia i worker interessati. Ciò elimina il percorso di errore prevedibile relativo al limite di memoria di PHP, ma lascia aperte altre possibilità di errori di allocazione. Verificare i limiti delle richieste e le protezioni di memoria dell’host o del container per ridurre i rischi di denial-of-service.

PHP ha inoltre pubblicato un avviso separato per CVE-2026-115560 il 23 ottobre. Riguarda le applicazioni che cambiano session.serialize_handler da php_binary o php_serialize a php utilizzando ini_set() prima di session_start(), con l’avanzamento del caricamento abilitato. Le configurazioni interessate dovrebbero disabilitare l’indicatore di avanzamento del caricamento in attesa di una correzione.

Acquista un piano di aggiornamento per le applicazioni legacy PHP da cui dipende la tua azienda

Contattaci

Verifica la presenza di SQL injection, XSS ed esecuzione di codice non sicuro

Una gestione inadeguata degli input degli utenti può esporre dati sensibili o consentire agli aggressori di eseguire codice dannoso. Consiglio di ricorrere alla revisione del codice per individuare i percorsi di input a rischio e al SAST per segnalare possibili vulnerabilità. Il DAST autorizzato testa l’applicazione in esecuzione, mentre i test di penetrazione aiutano a determinare quali punti deboli potrebbero essere sfruttati dagli aggressori. Le app realizzate tramite vibe coding possono presentare gli stessi difetti e richiedono gli stessi controlli.

SQL injection

L'iniezione SQL si verifica quando l'input dell'utente modifica la struttura di una query del database. Verifica come la tua applicazione costruisce le query, in particolare nei moduli di ricerca e nei report.

Per mantenere separati gli input dell'utente dai comandi SQL, utilizza le istruzioni preparate PDO:

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

Le istruzioni preparate mantengono i valori dei dati separati dalla sintassi SQL, come fa il segnaposto :email nell’esempio. Tuttavia, i segnaposto non possono rappresentare nomi di tabelle o colonne. Ad esempio, se gli utenti possono ordinare un report, selezionare le colonne consentite da un elenco definito nell’applicazione. Verificare le query interessate dopo aver apportato le modifiche.

Cross-site scripting

Il cross-site scripting (XSS) si verifica quando un'applicazione visualizza dati non attendibili che il browser può eseguire come codice. Controlla i modelli PHP per verificare che gli input degli utenti non vengano visualizzati senza un adeguato escaping, specialmente nei casi in cui l'escaping automatico sia disabilitato.

Ad esempio, se la vostra applicazione visualizza il nome di un utente come testo HTML, utilizzate htmlspecialchars() per convertire i caratteri speciali in modo che il browser li tratti come testo:

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

La protezione adeguata dipende dal contesto in cui compaiono i dati. JavaScript, gli URL e gli attributi HTML richiedono controlli e codifiche specifici per il contesto. Se gli utenti possono inviare HTML formattato, utilizzare un sanitizer HTML per rimuovere gli elementi non sicuri mantenendo la formattazione consentita.

Codice non sicuro ed esecuzione di comandi

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Approfondimento su autenticazione, sessioni e controllo degli accessi

Inizia dalle password. Non dovrebbero essere memorizzate in un formato leggibile. Verifica che la tua applicazione utilizzi PHP con le funzioni password_hash() e password_verify(), oppure i metodi equivalenti del framework. Cerca codice di hashing obsoleto che potrebbe non essere più sicuro.

Successivamente, verifica cosa succede quando qualcuno effettua l’accesso. L’applicazione dovrebbe generare un nuovo ID di sessione, in modo che un ID ottenuto prima dell’accesso non possa essere riutilizzato per accedere all’account. Verifica l’impostazione di session.use_strict_mode e quelle relative ai cookie, come Secure, HttpOnly e SameSite. Testa la rigenerazione dell’ID di sessione tramite il tuo framework, anche nel caso in cui arrivino più richieste contemporaneamente.

Ora verifica se gli utenti possono visualizzare dati che non appartengono loro. Crea due account di prova, ciascuno con la propria fattura. Accedi al primo account e modifica l’ID della fattura in una richiesta sostituendolo con quello appartenente al secondo account. Il server dovrebbe negare l’accesso a meno che quell’utente non disponga dell’autorizzazione.

Ripetere il test per la modifica delle fatture, il download dei file e le richieste API. Verificare che gli utenti normali non possano accedere alle funzioni di amministrazione. L’avere effettuato l’accesso non conferisce automaticamente a qualcuno l’autorizzazione ad accedere a ogni record. Il server deve verificare le autorizzazioni per ogni richiesta relativa a un record protetto o a un endpoint API.

Verifica la protezione CSRF

Un attacco CSRF induce il browser di un utente che ha effettuato l'accesso a compiere un'azione che non ha autorizzato, come la modifica dei dettagli dell'account. Inizia controllando i moduli e le richieste che modificano i dati, in particolare quelli autenticati tramite cookie di sessione.

Verifica la protezione CSRF nella tua applicazione Laravel o Symfony e controlla se ci sono route escluse. Laddove si applica la convalida dei token, testa le richieste con token mancanti o non validi. Verificate inoltre che le richieste contraffatte provenienti da un altro sito web non possano modificare i dati degli utenti. Controllate anche l’impostazione SameSite sui cookie di sessione.

In Laravel Blade, @csrf aggiunge un campo token nascosto a un modulo:


    @csrf

C’è un dettaglio importante in Laravel 13. Il suo middleware CSRF verifica innanzitutto l’intestazione Sec-Fetch-Site. Una richiesta della stessa origine può passare senza token, mentre le altre richieste ricorrono alla convalida del token per impostazione predefinita. Laravel disabilita inoltre la protezione CSRF durante i test automatizzati per impostazione predefinita, quindi assicurati che sia abilitata quando testi queste difese.

Per le API, il metodo di autenticazione è importante. Un’API stateless che utilizza token bearer nelle intestazioni di autorizzazione è generalmente soggetta a rischi CSRF diversi. Tuttavia, se la vostra SPA si basa sui cookie di sessione, necessita comunque di protezione contro le richieste contraffatte.

Caricamento e accesso sicuri ai file

Il caricamento dei file diventa un rischio per la sicurezza quando gli aggressori riescono a caricare file eseguibili o ad accedere a dati a cui non dovrebbero avere accesso. Verifica quali tipi e dimensioni di file accetta la tua applicazione, dove vengono archiviati i file caricati e chi può scaricarli. Verifica che i percorsi di caricamento e download non siano vulnerabili al path traversal, assicurati che i file caricati non possano essere eseguiti come PHP e controlla che i file .env, .git e di backup non siano accessibili pubblicamente.

Di seguito è riportato un PHP esempio che verifica il tipo MIME di un file caricato e lo salva con un nome generato casualmente:

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Caricamento non riuscito');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Tipo di file non supportato');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('Impossibile salvare il file caricato');
}

L'esempio presuppone il caricamento di un singolo file e l'esistenza di una directory privata con i permessi appropriati. La funzione move_uploaded_file() di PHP conferma che il file di origine è stato caricato tramite il meccanismo HTTP POST di PHP.

Il solo controllo MIME non è sufficiente a garantire la sicurezza dei caricamenti. Il codice di produzione richiede inoltre limiti di dimensione dei file imposti dal server, permessi di caricamento e download e la convalida del contenuto effettivo dei file. Ricodificare le immagini ove opportuno e considerare la scansione antimalware per i caricamenti a rischio più elevato. Se possibile, conservare i file al di fuori della radice web, limitare l’accesso al filesystem e impedire che i file caricati vengano eseguiti come PHP.

Proteggi i dati sensibili e le credenziali

Le password dei database, le chiavi API e i token di accesso esposti possono consentire agli aggressori di accedere alla tua applicazione o ai tuoi dati sensibili. Controlla il tuo codice sorgente e la cronologia Git alla ricerca di queste informazioni riservate. Strumenti come Gitleaks possono aiutarti a individuarle. Assicurati che i file .env non siano archiviati in Git né accessibili via web. Verifica inoltre chi può accedere alle informazioni riservate nelle pipeline CI/CD e controlla le immagini dei container e i log delle applicazioni alla ricerca di informazioni sensibili.

Conserva le credenziali in un gestore di credenziali o in un altro sistema con accesso limitato, anziché nel codice dell’applicazione. Limita chi può visualizzarle o modificarle e assegna a ciascuna applicazione solo le autorizzazioni necessarie.

Se una credenziale viene esposta, revocatela o sostituitela e aggiornate i servizi che la utilizzano. Rimuovete le copie esposte, verificate se qualcuno l’ha utilizzata senza autorizzazione e impedite che i segreti compaiano nei log futuri. La rimozione di un segreto dal codice non lo disabilita né lo cancella dai vecchi commit Git.

Richiedi una valutazione della sicurezza PHP effettuata da un esperto

Prenota una chiamata

Come stabilire le priorità, implementare e verificare le correzioni di sicurezza PHP

01
Assegnare una priorità alle vulnerabilità

Dare priorità ai sistemi esposti agli attacchi. Valutare il punteggio CVSS insieme alla SAPI PHP, all'esposizione a Internet, alle protezioni esistenti e all'impatto sul business. I carichi di lavoro mod_php non aggiornati ed esposti a Internet richiedono un intervento urgente, mentre le altre SAPI necessitano comunque di una valutazione.

02
Applicare le patch in modo sicuro

Registrare le applicazioni interessate, i pool di worker PHP e i digest delle immagini dei container. Eseguire i test in ambiente di staging e preparare un piano di ripristino prima della distribuzione. Applicare le patch ai pacchetti interessati o ricompilare le immagini, quindi riavviare o sostituire tutti i worker interessati. Le regole WAF e le misure di mitigazione a livello di configurazione possono ridurre l’esposizione a specifici percorsi di exploit. Tuttavia, non correggono il runtime vulnerabile.

03
Verifica delle misure correttive

Verificare quale versione di PHP gestisce le richieste in produzione e confermare lo stato delle patch, inclusi eventuali backport del fornitore. Verificare che i worker interessati siano stati riavviati o sostituiti, eseguire i test di regressione e ripetere il controllo di sicurezza che in precedenza aveva dato esito negativo. Monitorare l'ambiente di produzione per individuare eventuali errori dopo la distribuzione.

04
Indagare su un’eventuale violazione della sicurezza

L'applicazione della patch risolve la vulnerabilità. Qualsiasi compromissione avvenuta in precedenza richiede comunque un'indagine. Esaminare i log del server, i crash dei worker, i file sconosciuti e le attività di rete sospette. Su mod_php, PHP2Shell potrebbe essere eseguito prima che inizi la registrazione dei log dell'applicazione, pertanto la pulizia dei log del framework non può escludere un attacco. Segnalare i segnali di allarme al team di risposta agli incidenti e conservare le prove.

05
Garantire la sicurezza

Monitorare le nuove vulnerabilità relative a PHP e alle dipendenze, e aggiungere controlli di sicurezza al CI/CD. Basare le valutazioni periodiche sull’esposizione delle applicazioni e sul rischio aziendale, e effettuare una nuova valutazione a seguito di modifiche significative o divulgazioni critiche.

arrow-icon.arrow-icon.
01 Assegnare una priorità alle vulnerabilità

Dare priorità ai sistemi esposti agli attacchi. Valutare il punteggio CVSS insieme alla SAPI PHP, all'esposizione a Internet, alle protezioni esistenti e all'impatto sul business. I carichi di lavoro mod_php non aggiornati ed esposti a Internet richiedono un intervento urgente, mentre le altre SAPI necessitano comunque di una valutazione.

arrow-icon.arrow-icon.
02 Applicare le patch in modo sicuro

Registrare le applicazioni interessate, i pool di worker PHP e i digest delle immagini dei container. Eseguire i test in ambiente di staging e preparare un piano di ripristino prima della distribuzione. Applicare le patch ai pacchetti interessati o ricompilare le immagini, quindi riavviare o sostituire tutti i worker interessati. Le regole WAF e le misure di mitigazione a livello di configurazione possono ridurre l’esposizione a specifici percorsi di exploit. Tuttavia, non correggono il runtime vulnerabile.

arrow-icon.arrow-icon.
03 Verifica delle misure correttive

Verificare quale versione di PHP gestisce le richieste in produzione e confermare lo stato delle patch, inclusi eventuali backport del fornitore. Verificare che i worker interessati siano stati riavviati o sostituiti, eseguire i test di regressione e ripetere il controllo di sicurezza che in precedenza aveva dato esito negativo. Monitorare l'ambiente di produzione per individuare eventuali errori dopo la distribuzione.

arrow-icon.arrow-icon.
04 Indagare su un’eventuale violazione della sicurezza

L'applicazione della patch risolve la vulnerabilità. Qualsiasi compromissione avvenuta in precedenza richiede comunque un'indagine. Esaminare i log del server, i crash dei worker, i file sconosciuti e le attività di rete sospette. Su mod_php, PHP2Shell potrebbe essere eseguito prima che inizi la registrazione dei log dell'applicazione, pertanto la pulizia dei log del framework non può escludere un attacco. Segnalare i segnali di allarme al team di risposta agli incidenti e conservare le prove.

arrow-icon.arrow-icon.
05 Garantire la sicurezza

Monitorare le nuove vulnerabilità relative a PHP e alle dipendenze, e aggiungere controlli di sicurezza al CI/CD. Basare le valutazioni periodiche sull’esposizione delle applicazioni e sul rischio aziendale, e effettuare una nuova valutazione a seguito di modifiche significative o divulgazioni critiche.

Esempio pratico: una patch di produzione che sembra aver avuto esito positivo, ma in realtà non è così

Un negozio basato su Symfony utilizza PHP 8.3 con nginx e PHP-FPM. L'amministratore aggiorna i pacchetti del sistema operativo ed esegue php -v. Il comando mostra una versione aggiornata, quindi tutto sembra a posto. Tuttavia, php -v controlla solo il binario PHP dalla riga di comando.

Le richieste dei clienti passano ancora attraverso nginx verso i worker PHP-FPM avviati prima dell’aggiornamento. Anche i processi in background vengono eseguiti in un container separato con un PHP di base vulnerabile. I pacchetti potrebbero essere stati aggiornati sul server, ma questi carichi di lavoro continuano a utilizzare il codice precedente.

PHP build checks for web, workers, and CLI.

Per completare l'applicazione della patch, il team deve identificare tutte le applicazioni e i pool di worker interessati, riavviare i worker FPM e ridistribuire il container della coda con un'immagine aggiornata. Deve quindi verificare che i processi PHP in esecuzione utilizzino build corrette o backport verificati dal fornitore.

Testare il checkout e il caricamento dei file nell’ambiente di staging, eseguire gli smoke test in produzione e ripetere i controlli di sicurezza che in precedenza avevano dato esito negativo. Il record di distribuzione dovrebbe includere la SAPI PHP che gestisce il traffico web, le versioni verificate dei pacchetti o i digest delle immagini, le prove del riavvio e dei test, nonché il responsabile.

Il superamento di un audit di Composer non è prova che PHP2Shell sia stato risolto. Quel comando verifica le dipendenze, non l’PHP interprete che gestisce le richieste web.

Esaminare l’ID utente del PHP worker, le directory scrivibili, i segreti montati, i permessi del database e l’accesso alla rete in uscita. Questi fattori determinano se un aggressore possa modificare i file dell’applicazione, leggere le credenziali o raggiungere altri sistemi. Il principio del privilegio minimo e la segmentazione della rete possono limitare i danni nel caso in cui un worker venga compromesso, ma rimane comunque necessario applicare una patch all’interprete.

Il comando `php -v` mostra la versione di PHP dalla riga di comando, ma non permette di verificare quale interprete gestisca il traffico di produzione né se i worker a esecuzione prolungata stiano ancora utilizzando la build vulnerabile. Con PHP2Shell, verifichiamo innanzitutto il runtime attivo, quindi esaminiamo le dipendenze e il codice dell'applicazione. Consideriamo la correzione completa solo dopo aver verificato che la versione aggiornata stia effettivamente gestendo le richieste di produzione.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Responsabile GRC, Cybersecurity e Sostenibilità

In che modo Innowise può aiutarti a proteggere le tue applicazioni PHP

Noi di Innowise uniamo competenze nello sviluppo PHP e nella sicurezza. I nostri oltre 100 sviluppatori PHP hanno portato a termine oltre 250 progetti, mentre i nostri oltre 50 ingegneri di sicurezza informatica contribuiscono a identificare e risolvere le vulnerabilità. Il nostro lavoro è inoltre supportato dalle certificazioni ISO/IEC 27001:2022 e ISO 9001:2015.

Verifichiamo le vostre applicazioni PHP alla ricerca di problemi di sicurezza, incluse dipendenze vulnerabili e componenti obsoleti. I nostri sviluppatori si occupano delle correzioni e degli aggiornamenti necessari, mentre i tecnici della sicurezza testano le modifiche prima del rilascio. Se non sapete da dove iniziare, il nostro team di consulenza sulla sicurezza IT può valutare i rischi e aiutarvi a stabilire le priorità del lavoro.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

I nostri progetti PHP

Riprogettazione e ricostruzione del sito web di MedSpa Network
Innowise ha ricostruito il sito web di MedSpa Network con WordPress dando al team la possibilità di gestire in autonomia gli aggiornamenti quotidiani dei contenuti.
2 mesi dall'avvio al lancio
3-5 lead a settimana, rispetto a 1 al mese
Scopri il progetto
Recensione del cliente
Scopri il progetto
Client review logo. Recensione del cliente
MedSpa Network website redesign and rebuild.
Bot IA per la campagna marketing di TBC Bank
Innowise ha sviluppato un bot Telegram bilingue che genera selfie con il testimonial di TBC Bank, una star del calcio, grazie all'IA.
3,000 utenti coinvolti
2 lingue supportate
Scopri il progetto
Recensione del cliente
Scopri il progetto
Client review logo. Recensione del cliente
AI Telegram bot..
Definizione della strategia di prodotto per la piattaforma di prestiti in bitcoin di Bitlendex
Innowise ha gestito la fase di discovery per Bitlendex aiutando il cliente a trasformare un'idea iniziale in un modello di business validato e in un MVP con requisiti definiti.
1 mese per completare la fase di discovery
Scopri il progetto
Scopri il progetto
Defining the product strategy for Bitlendex’s bitcoin lending platform.
Sistema di consulenza finanziaria per Bonnfinanz
Innowise ha aiutato Bonnfinanz a sviluppare un sistema web per la consulenza e la gestione amministrativa, che permette ai consulenti di lavorare da dispositivi mobili e interagire direttamente con i clienti.
Scopri il progetto
Scopri il progetto
Financial advisory system for Bonnfinanz..
Piattaforma di ricarica per veicoli elettrici con fatturazione flessibile
Innowise ha modernizzato la piattaforma di mobilità elettrica di SMART/LAB, migliorando le funzioni di fatturazione, pagamento, gestione delle transazioni e reportistica.
>50% di velocità in più nell'elaborazione di fatture e pagamenti
Scopri il progetto
Scopri il progetto
EV charging platform with flexible billing.
Trasformazione cloud-native DevOps di FinXP
Innowise ha aiutato FinXP a modernizzare l'infrastruttura per i servizi finanziari migrando API e applicazioni legacy basate su PHP verso un'architettura cloud-native.
11 app migrate ad Azure App Service
100% Infrastructure as Code
Scopri il progetto
Scopri il progetto
FinXP’s cloud-native DevOps transformation.
SEO tecnica per una piattaforma e-commerce
Innowise ha risolto problemi di SEO tecnica e prestazioni sulla piattaforma e-commerce di Officine 08.
<500 ms tempo di risposta del server
5 mesi per portare a termine il progetto
Scopri il progetto
Recensione del cliente
Scopri il progetto
Client review logo. Recensione del cliente
SEO tecnico per piattaforma e-commerce.
Sviluppo continuativo di una piattaforma di abbonamenti ai profumi
Innowise ha aiutato Scentbird ad ampliare la propria piattaforma di abbonamento per favorire nuove esperienze di acquisto e la crescita internazionale.
4 anni di supporto costante
Scopri il progetto
Recensione del cliente
Scopri il progetto
Client review logo. Recensione del cliente
Continuous development of a fragrance subscription platform.
01 / 01
Close popup icon

Conclusione

PHP2Shell ha messo in luce una grave vulnerabilità nell’interprete PHP stesso. Gli aggiornamenti dei framework e i controlli delle dipendenze non risolvono le vulnerabilità a quel livello. Le aziende devono identificare ogni PHP in esecuzione che gestisce le richieste web, installare gli aggiornamenti di sicurezza e verificare che i server di produzione stiano utilizzando le versioni corrette.

La sicurezza di PHP richiede inoltre controlli regolari del codice delle applicazioni, della configurazione e dei controlli di accesso, in particolare dopo la divulgazione di vulnerabilità critiche o aggiornamenti importanti. Se avete bisogno di aiuto per valutare la vostra esposizione o verificare le correzioni, Innowise offre I team di consulenza sulla sicurezza IT e di valutazione della sicurezza informatica di Innowise possono supportarvi in questo lavoro.

FAQ

La tua applicazione potrebbe essere a rischio se il tuo server utilizza una versione di PHP che non è stata aggiornata per le vulnerabilità CVE-2026-109618 e CVE-2026-109619. Verifica quale versione di PHP è effettivamente in esecuzione e se il tuo provider di hosting ha applicato le correzioni. Apache mod_php presenta il rischio confermato più elevato, ma è necessario controllare anche PHP-FPM. Poiché le vulnerabilità risiedono nel PHP stesso, l’aggiornamento di WordPress o di un altro framework non le risolverà.

Le correzioni per PHP2Shell sono disponibili in PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Alcuni fornitori Linux hanno retroportato le patch alle versioni precedenti, quindi controllate l'avviso del vostro fornitore. Assicuratevi che i worker PHP in esecuzione utilizzino la versione con la patch. Su Windows, installate i pacchetti aggiornati del 26 ottobre che terminano con -1, i quali risolvono anche una vulnerabilità Brotli separata.

Se non è possibile aggiornare immediatamente PHP, limitare, ove possibile, l'accesso pubblico alle applicazioni interessate. Per i siti che devono rimanere online, l’amministratore del server può applicare misure temporanee indicate nell’avviso di sicurezza relativo a PHP, come limitare le dimensioni delle richieste o disabilitare l’avanzamento del caricamento delle sessioni. Prova queste modifiche per assicurarti che il sito funzioni ancora. Esse riducono solo il rischio, quindi l’installazione di una versione corretta di PHP rimane urgente.

No. L'aggiornamento di PHP risolve le vulnerabilità nel runtime di PHP, ma non risolverà i problemi di sicurezza nel codice della tua applicazione, nei plugin obsoleti o nella configurazione del server. È necessario verificarle e risolverle separatamente.

Consiglio di verificare almeno una volta al mese la presenza di vulnerabilità note nelle applicazioni PHP, effettuando controlli più frequenti per i sistemi ad alto rischio. Monitorate costantemente gli avvisi di sicurezza e le dipendenze relative a PHP e pianificate verifiche più approfondite in base all’esposizione della vostra applicazione e al rischio aziendale. È importante eseguire test aggiuntivi dopo aggiornamenti importanti o la divulgazione di vulnerabilità critiche.

Controlla PHP gli avvisi di sicurezza e i bollettini del tuo provider di hosting o del fornitore del sistema operativo per individuare eventuali vulnerabilità note. Utilizza composer audit --locked per verificare le dipendenze, l'analisi statica e la revisione del codice per individuare eventuali problemi a livello di applicazione, e OWASP ZAP per testare la tua applicazione web con le autorizzazioni necessarie. Per verificare le patch di sicurezza, controlla la versione di PHP in esecuzione in produzione e le eventuali correzioni retroportate dal tuo fornitore.

Sì. Gli aggiornamenti possono causare problemi di compatibilità con codice o estensioni meno recenti. Testateli in ambiente di staging prima di aggiornare l'applicazione live e preparate un piano di ripristino nel caso in cui qualcosa non funzioni correttamente.

Correlare i log del reverse proxy, di Apache/nginx, PHP-FPM e dell'EDR/host. Cerca arresti anomali dei worker, file o processi sospetti, traffico in uscita inaspettato e segni di esposizione delle credenziali. I log delle applicazioni potrebbero non rilevare gli exploit in fase di esecuzione di PHP che si verificano prima che il framework inizi a registrare i log. Se riscontri attività sospette, avvia la risposta all'incidente e conserva le prove forensi.

Mostra di più Mostra meno

Indice dei contenuti

Scopri quali PHP carichi di lavoro necessitano per primi di un aggiornamento di sicurezza

Valuta la mia PHP esperienza

    Contattaci

    Prenota una chiamata oppure compila il modulo qui sotto. Ti contatteremo non appena avremo elaborato la richiesta.

    Inviaci un messaggio vocale
    Allega i documenti
    Carica file

    È possibile allegare 1 file di dimensioni massime di 2 MB. Formati di file validi: pdf, jpg, jpeg, png.

    Cliccando su «Invia», acconsenti al trattamento dei tuoi dati personali da parte di Innowise, in conformità con la nostra Informativa sulla privacy, per fornirti informazioni pertinenti. Inserendo il tuo numero di telefono, accetti che possiamo contattarti tramite chiamate vocali, SMS e app di messaggistica. Potrebbero essere applicati costi per chiamate, messaggi e traffico dati.

    Puoi anche inviarci la tua richiesta
    a contact@innowise.com
    Cosa succede dopo?
    1

    Una volta ricevuta e presa in carico la richiesta, ti ricontatteremo per approfondire le esigenze del progetto e firmare un accordo di riservatezza.

    2

    Dopo aver chiarito le esigenze, obiettivi e aspettative, il nostro team elabora una proposta che definisce le attività previste, la composizione del team, le tempistiche e i costi stimati.

    3

    Fisseremo un incontro per discutere la proposta e definire tutti i dettagli.

    4

    Infine, firmeremo il contratto e inizieremo subito a lavorare sul tuo progetto.

    Contenuti correlati

    Blog
    Generative AI trends in 2026: key technologies and future outlook.
    Tendenze dell'IA generativa nel 2026: tecnologie chiave e prospettive future
    Scopri le principali tendenze dell'IA generativa nel 2026. Scopri come i vari settori stanno utilizzando l'IA generativa, quali sono i rischi e quali saranno i prossimi sviluppi.
    Michael Labutin
    5 novembre 2026
    Blog
    AI discoverability: how to get your brand found, cited, and recommended by AI.
    Visibilità nell'IA: come fare in modo che il tuo marchio venga individuato, citato e raccomandato dall'IA
    Il tuo marchio potrebbe essere ben posizionato su Google e rimanere comunque invisibile a ChatGPT. Vediamo cosa può fare la "scopribilità" tramite IA al riguardo.
    Yuliya Pantsiuk
    4 novembre 2026
    Blog
    AI in supply chain and logistics: use cases, benefits, and implementation.
    L'intelligenza artificiale nella catena di approvvigionamento e nella logistica: casi d'uso, vantaggi e implementazione
    L'intelligenza artificiale sta rivoluzionando il settore della logistica, e i tuoi concorrenti lo sanno bene. Scopri dove viene utilizzata, quali risparmi consente e come recuperare il ritardo.
    Philip Tikhanovich
    4 novembre 2026
    Blog
    AI in social media: use cases, benefits, and trends.
    L'intelligenza artificiale nei social media: casi d'uso, vantaggi e tendenze
    Feed, filtri, traduzione, moderazione: l’intelligenza artificiale è ovunque sui social media. Diamo un’occhiata dietro le quinte.
    Philip Tikhanovich
    30 ottobre 2026
    Blog
    AI in CRM: use cases, benefits, and implementation.
    IA nel CRM: casi d'uso, vantaggi e implementazione
    Quali funzionalità dei CRM basati sull'intelligenza artificiale meritano davvero tutta questa attenzione? Analizziamo i casi d'uso, le piattaforme, i rischi e il ROI.
    Raman Karabach
    14 ottobre 2026
    Blog
    AI chatbots in healthcare: use cases, benefits, and implementation.
    Chatbot basati sull'intelligenza artificiale nel settore sanitario: casi d'uso, vantaggi e implementazione
    Una guida approfondita ai chatbot basati sull'intelligenza artificiale nel settore sanitario: casi d'uso reali, vantaggi e aspetti chiave dell'integrazione.
    Roman Sen
    24 settembre 2026
    Blog
    AI in medical imaging: applications, benefits, and implementation.
    L'intelligenza artificiale nella diagnostica per immagini: applicazioni, vantaggi e implementazione
    Uno sguardo lucido su come l’intelligenza artificiale viene utilizzata oggi nell’imaging medico.
    Aleh Yafimau
    1 settembre 2026
    Blog
    LLM-as-a-judge: how we evaluate AI systems at scale.
    LLM-as-a-judge: come valutiamo i sistemi di IA su larga scala
    Valuta i risultati generati dai modelli LLM con criteri di valutazione più rigorosi, punteggi più chiari e meno punti ciechi.
    Philip Tikhanovich
    22 luglio 2026
    Blog
    Best 10 data modernization companies in 2026.
    Le 10 migliori aziende specializzate nella modernizzazione dei dati nel 2026
    Confronta le migliori aziende specializzate nella modernizzazione dei dati e scegli un partner per la gestione dei dati legacy, nel cloud e predisposti per l'intelligenza artificiale.
    Philip Tikhanovich
    16 luglio 2026
    Blog
    Microsoft Dynamics 365 for financial services: a complete guide.
    Microsoft Dynamics 365 per i servizi finanziari: una guida completa
    Le banche adorano i sistemi. I team detestano quelli mal funzionanti. È qui che Dynamics 365 può dare una mano.
    Siarhei Sukhadolski
    13 luglio 2026
    Blog
    Best 9 ERP consulting companies in 2026.
    Le 9 migliori società di consulenza ERP nel 2026
    Confronta le 9 migliori società di consulenza ERP del 2026. Esamina le competenze e i settori di specializzazione e scopri alcuni consigli per scegliere il partner più adatto alle tue esigenze.
    Kiryl Drabysheuski
    10 luglio 2026
    Blog
    Enterprise AI adoption trends 2026.
    Tendenze nell'adozione dell'IA nelle aziende nel 2026
    Le tendenze più significative del 2026 nel campo dell'intelligenza artificiale e come stanno cambiando per sempre le aziende.
    Philip Tikhanovich
    7 luglio 2026

    Altri servizi che copriamo

    Operazioni
    IAOps BPA Servizi IT gestiti Consulenza MLOps RPA
    Scopri di più
    QA
    Test automatizzati QA per app e-commerce Testing ERP Pentesting Consulenza QA Ingegneri QA Test di sicurezza Test Penetration test web
    Scopri di più

    arrow