Bollettini sulla sicurezza

Di seguito sono descritti i bollettini sulla sicurezza relativi ad Apigee.

Per ricevere gli ultimi bollettini di sicurezza, esegui una delle seguenti operazioni:

  • Aggiungi l'URL di questa pagina al tuo aggregatore di feed.
  • Aggiungi l'URL del feed direttamente al tuo lettore di feed: https://cloud.google.com/feeds/apigee-security-bulletins.xml

GCP-2026-010

Pubblicato il: 13/02/2026

Descrizione

Descrizione Gravità Note

È stata identificata una vulnerabilità nella piattaforma Apigee che avrebbe potuto consentire a un utente malintenzionato con autorizzazioni a livello di amministratore o sviluppatore nel proprio ambiente Apigee di elevare i privilegi e accedere ai dati cross-tenant.

Nello specifico, una vulnerabilità nella tecnologia sandbox di Apigee X consentiva l'utilizzo di un endpoint link-local per accedere ai token del account di servizio (P4SA) all'interno di un progetto tenant cliente. Sfruttando questa identità, un malintenzionato potrebbe teoricamente leggere i metadati di Analytics o manomettere i record di monitoraggio interni in altre organizzazioni (tenant) Apigee.

Che cosa devo fare?

Non è richiesta alcuna azione da parte del cliente. Google ha implementato una strategia di mitigazione a più livelli per risolvere il problema:

  • Mitigazione dello sfruttamento dei token:il vettore di exploit per il token del service account Apigee nei pod di runtime è stato mitigato.
  • Principio del privilegio minimo:le autorizzazioni del account di servizio Apigee sono state limitate per impedire modifiche non autorizzate.
  • Isolamento dei dati:è stato rimosso l'accesso per i service account a livello di cartella ai bucket Google Cloud Storage multi-tenant.

Google ha confermato che, sebbene i record di monitoraggio interni fossero teoricamente accessibili, questi vengono utilizzati solo internamente da Google e la loro esposizione non influisce sulla sicurezza o sull'integrità dei dati dei clienti all'interno di Apigee.

 Alta CVE-2025-13292

GCP-2025-023

Pubblicato il: 05/05/2025

Descrizione Gravità Note

Questo bollettino riguarda potenziali lacune di sicurezza che potrebbero essere sfruttate se non affrontate nelle policy JavaCallout e PythonScript che sono state rilevate e risolte. Questi criteri potrebbero comportare l'esecuzione di codice da remoto (RCE) e l'escalation dei privilegi non autorizzati all'interno dell'ambiente di runtime Apigee. Questi possibili exploit richiedono l'accesso interno di utenti autorizzati (utenti con il privilegio di deployment dei proxy) per essere sfruttati. Queste potenziali vulnerabilità derivano da un sandboxing insufficiente per scenari come l'accesso tramite reflection e lo spoofing degli oggetti di autorizzazione per bypassare il gestore della sicurezza.

Prodotti interessati

L'impatto è limitato ai criteri JavaCallout e PythonScript. Ciò include i deployment sulle seguenti piattaforme Apigee:

  • Apigee
  • Apigee Edge for Public Cloud
  • Apigee hybrid
  • Apigee Edge for Private Cloud

Che cosa devo fare?

Esegui le seguenti azioni per ogni prodotto interessato:

Apigee

Non è richiesta alcuna azione per i clienti che utilizzano la versione Google Cloud di Apigee. Le correzioni delle vulnerabilità sono state applicate alla release 1-14-0-apigee-8 di Apigee.

Se il team di rilascio non è in grado di eseguire l'implementazione del rilascio per le tue organizzazioni, un TAM o un rappresentante dell'assistenza ti contatterà per correggere eventuali bundle proxy JavaCallout interessati.

Apigee hybrid

Devi eseguire l'upgrade a una delle seguenti release di patch di sicurezza:

Versione principale ibrida Rilascio della patch di sicurezza per la versione secondaria interessata
1,12 1.12.4
1,13 1.13.3
1,14 1.14.1
1,11 1.11.2 hotfix3
Alta

Apigee Edge for Public Cloud

Non è necessario alcun intervento da parte dei clienti Apigee Edge. Sono state applicate correzioni all'ultimo runtime Edge. Se sei un cliente che non può essere aggiornato all'ultima versione di Edge a causa di elementi di azione in attesa noti, un rappresentante dell'assistenza clienti ti contatterà.

Apigee Edge for Private Cloud

Se sei un utente di Edge for Private Cloud, devi esaminare le tue norme JavaCallout e PythonScript per assicurarti di utilizzare codice e librerie provenienti da fonti attendibili. Le modifiche a queste norme richiedono l'accesso interno autorizzato (utenti con autorizzazioni per il deployment di proxy), pertanto ti consigliamo di controllare le autorizzazioni per assicurarti che solo gli utenti attendibili mantengano questo accesso. Sono state applicate correzioni delle vulnerabilità alle release 4.52.02 e 4.53.00 di Edge Private Cloud.

GCP-2024-040

Pubblicato il: 02/07/2024

Questo bollettino include dettagli specifici per ciascuno di questi prodotti Apigee:

Edge Public Cloud

Descrizione Gravità Note

Di recente è stata scoperta in OpenSSH una vulnerabilità di esecuzione di codice remoto, CVE-2024-6387. La vulnerabilità sfrutta una race condition che potrebbe essere utilizzata per ottenere l'accesso a una shell remota, consentendo agli autori di attacchi di ottenere l'accesso root ai nodi GKE. Al momento della pubblicazione, Apigee Edge per il cloud pubblico non è sfruttabile e sono in atto misure di mitigazione.

Anche se questa CVE non è sfruttabile, Apigee eseguirà l'upgrade dei workload per risolvere il problema.

Che cosa devo fare?

Non è richiesto alcun elemento di azione da parte degli utenti Apigee.

L'applicazione di patch per i carichi di lavoro verrà eseguita nei prossimi giorni e il bollettino sulla sicurezza verrà aggiornato al termine dell'applicazione delle patch.

 Critico

Edge Private Cloud

Descrizione Gravità

Di recente è stata scoperta in OpenSSH una vulnerabilità di esecuzione di codice remoto, CVE-2024-6387. La vulnerabilità sfrutta una race condition che potrebbe essere utilizzata per ottenere l'accesso a una shell remota, consentendo agli autori di attacchi di ottenere l'accesso root ai nodi VM. I clienti di Edge Private Cloud sono proprietari e gestiscono le VM/gli host fisici in cui è implementato Edge Private Cloud.

Versione Impatto
OpenSSH < 4.4p1 Vulnerabile
4.4p1 <= OpenSSH < 8.5p1 Non vulnerabile
8.5p1 <= OpenSSH < 9.8p1 Vulnerabile

Che cosa devo fare?

Controlla la versione di OpenSSH eseguendo il comando ssh -V e convalidala. Se utilizzi una delle versioni di OpenSSH interessate, esegui l'aggiornamento a una versione NON vulnerabile a questo CVE. OpenSSH ha rilasciato la versione 9.8p1 il 1° luglio 2024.

 Critico

Edge Microgateway

Descrizione Gravità Note

Di recente è stata scoperta in OpenSSH una vulnerabilità di esecuzione di codice remoto, CVE-2024-6387. La vulnerabilità sfrutta una race condition che potrebbe essere utilizzata per ottenere l'accesso a una shell remota, consentendo agli autori di attacchi di ottenere l'accesso root ai nodi VM. I clienti di Edge Microgateway sono proprietari e gestiscono le VM/gli host fisici in cui viene implementato Edge Microgateway.

Versione Impatto
OpenSSH < 4.4p1 Vulnerabile
4.4p1 <= OpenSSH < 8.5p1 Non vulnerabile
8.5p1 <= OpenSSH < 9.8p1 Vulnerabile

Che cosa devo fare?

Controlla la versione di OpenSSH eseguendo i comandi ssh -V e convalida la versione di OpenSSH. Se utilizzi una delle versioni di OpenSSH interessate, esegui l'aggiornamento a una versione NON vulnerabile a questo CVE. OpenSSH ha rilasciato la versione 9.8p1 il 1° luglio 2024.

 Critico

Apigee

Descrizione Gravità Note

Di recente è stata scoperta in OpenSSH una vulnerabilità di esecuzione di codice remoto, CVE-2024-6387. La vulnerabilità sfrutta una race condition che potrebbe essere utilizzata per ottenere l'accesso a una shell remota, consentendo agli autori di attacchi di ottenere l'accesso root ai nodi GKE. Al momento della pubblicazione, Apigee non è sfruttabile e sono in atto misure di mitigazione.

Anche se questa vulnerabilità CVE non è sfruttabile, Apigee eseguirà l'upgrade dei workload per risolvere la CVE-2024-6387.

Che cosa devo fare?

Non è richiesto alcun elemento di azione da parte degli utenti Apigee. L'applicazione di patch per i carichi di lavoro verrà eseguita nei prossimi giorni e il bollettino di sicurezza verrà aggiornato al termine dell'applicazione delle patch.

Nota: se i gruppi di istanze gestite vengono implementati in un progetto cliente per il bilanciamento del carico in direzione nord, in particolare InternalRouting (VPC) e ExternalRouting (MIG), verifica la versione di OpenSSH installata. Se la versione è vulnerabile al CVE, esegui l'aggiornamento a OpenSSH versione 9.8p1 rilasciata il 1° luglio 2024 autonomamente, poiché Apigee non gestisce questi MIG.

 Critico

Apigee hybrid

Descrizione Gravità Note

Di recente è stata scoperta in OpenSSH una vulnerabilità di esecuzione di codice remoto, CVE-2024-6387. La vulnerabilità sfrutta una race condition che potrebbe essere utilizzata per ottenere l'accesso a una shell remota, consentendo agli autori degli attacchi di ottenere l'accesso root ai nodi GKE. Al momento della pubblicazione, le immagini ibride non sono vulnerabili perché OpenSSH non è incluso in nessuna delle immagini container ibride. Tuttavia, se il sistema operativo host/nodo GKE è in esecuzione con le versioni vulnerabili di OpenSSH riportate di seguito, i tuoi cluster ibridi saranno sfruttabili.

Versione Impatto
OpenSSH < 4.4p1 Vulnerabile
4.4p1 <= OpenSSH < 8.5p1 Non vulnerabile
8.5p1 <= OpenSSH < 9.8p1 Vulnerabile

Che cosa devo fare?

Questo problema è stato risolto nel bollettino sulla sicurezza dell'assistenza clienti Google Cloud GCP-2024-040.

Per istruzioni e maggiori dettagli, consulta i seguenti bollettini:

 Critico

GCP-2024-006

Pubblicato il: 05/02/2024

Descrizione Gravità Note

Quando un proxy Apigee API Management si connette a un endpoint di destinazione o a un server di destinazione, il proxy non esegue la convalida del nome host per il certificato presentato dall'endpoint di destinazione o dal server di destinazione per impostazione predefinita. Se la convalida del nome host non è abilitata utilizzando una delle seguenti opzioni, i proxy Apigee che si connettono a un endpoint di destinazione o a un server di destinazione potrebbero essere a rischio di attacco man-in-the-middle da parte di un utente autorizzato. Per saperne di più, consulta Configurazione di TLS da Edge al backend (cloud e cloud privato).

Prodotti interessati

Sono interessati i deployment dei proxy Apigee sulle seguenti piattaforme Apigee:

  • Apigee Edge for Public Cloud
  • Apigee Edge for Private Cloud

Che cosa devo fare?

I clienti possono utilizzare una delle seguenti opzioni per attivare questa convalida:

Opzione 1: aggiungi una configurazione al proxy

Puoi attivare la convalida dell'endpoint di destinazione o del server di destinazione aggiungendo una configurazione <CommonName> alla sezione SSLInfo dell'elemento <HTTPTargetConnection> nella configurazione del proxy, come mostrato di seguito:

<HTTPTargetConnection>
  <SSLInfo>
    <Enabled>true</Enabled>
    <TrustStore>ref://mytruststoreref</TrustStore>
    <CommonName>*.example.com</CommonName>
  </SSLInfo>
  <URL>https://my.example.com/</URL>
</HTTPTargetConnection>

Se questa configurazione è presente nell'elemento <HTTPTargetConnection> della configurazione del proxy, Apigee utilizzerà il valore specificato in <CommonName> per la convalida del nome host. In questo campo è possibile utilizzare i caratteri jolly.

Apigee consiglia questo approccio. Puoi testare i proxy singolarmente per verificare che la convalida funzioni come previsto, con un potenziale minimo di interruzione del traffico. Per ulteriori informazioni sul test della convalida del nome host nei proxy e sulla visualizzazione degli errori, vedi Utilizzo dello strumento Trace.

Opzione 2: imposta un flag a livello di organizzazione

Puoi impostare un flag a livello di organizzazione Apigee per attivare la convalida del nome host per tutti i proxy e i target di cui è stato eseguito il deployment nella tua organizzazione. Se il flag features.strictSSLEnforcement è impostato su true nelle proprietà dell'organizzazione, la convalida del nome host verrà applicata ogni volta che il proxy si connette a un endpoint di destinazione o a un server di destinazione.

Nota: sebbene questa opzione possa aiutarti ad attivare la funzionalità in tutta l'organizzazione, possono verificarsi errori di convalida del nome host se le destinazioni non presentano i certificati previsti.

  • Per i deployment di Apigee Edge Public Cloud:

    Contatta l'assistenzaGoogle Cloud per impostare il flag features.strictSSLEnforcement su true nelle proprietà dell'organizzazione.

    Nota: se abiliti questo flag, il controllo SSL verrà applicato a tutti gli ambienti di un'organizzazione e a tutti i proxy di cui è stato eseguito il deployment in questi ambienti.

  • Per i deployment di Apigee Edge for Private Cloud :

    Il flag features.strictSSLEnforcement può essere impostato su true dall'amministratore dell'organizzazione o del sistema. Per saperne di più sull'impostazione del flag, consulta Aggiornamento delle proprietà dell'organizzazione.

    Nota: quando aggiorni i flag a livello di organizzazione utilizzando l'API Organizations, assicurati di includere tutti i flag esistenti nella richiesta POST per evitare di sovrascrivere le impostazioni di configurazione precedenti.

    Una volta impostato il flag, ogni elaboratore di messaggi deve essere riavviato singolarmente affinché la modifica abbia effetto. Utilizza il seguente comando:

    apigee-service edge-message-processor restart

    Per eseguire il rollback di questa modifica, utilizza la stessa API Organizations per impostare il flag su false e poi riavvia ogni processore di messaggi.

    Nota: se abiliti questo flag, il controllo SSL verrà applicato a tutti gli ambienti di un'organizzazione e a tutti i proxy di cui è stato eseguito il deployment in questi ambienti. Tuttavia, se <IgnoreValidationErrors> è impostato su true, eventuali errori di convalida rilevati verranno ignorati.

Apigee consiglia di implementare questa modifica prima negli ambienti non di produzione, per assicurarsi che la convalida funzioni come previsto e non comporti interruzioni della produzione. Se la convalida del nome host non va a buon fine per una delle destinazioni, viene restituito il seguente messaggio di errore:

{"fault":{"faultstring":"SSL Handshake failed java.security.cert.CertificateException: No subject alternative DNS name matching example.com found.","detail":{"errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"}}}
 		Alta

GCP-2023-032

Pubblicato il: 13/10/2023

Aggiornamento: 2023-11-03

Descrizione Gravità Note

Aggiornamento del 03/11/2023: è stato aggiunto un problema noto per Apigee Edge for Private Cloud.

Di recente è stata scoperta una vulnerabilità Denial of Service (DoS) in più implementazioni del protocollo HTTP/2 (CVE-2023-44487), incluso il servizio Apigee Ingress (Cloud Service Mesh) utilizzato da Apigee X e Apigee Hybrid. La vulnerabilità potrebbe causare un attacco DoS alla funzionalità di gestione delle API Apigee.

Prodotti interessati

  • Apigee X

    Sono interessate le implementazioni di Apigee X accessibili tramite un bilanciatore del carico di rete (livello 4) o un bilanciatore del carico di rete personalizzato di livello 4. Google Cloud È stata applicata una correzione rapida a tutte le istanze Apigee X.

  • Apigee hybrid

    Sono interessate le istanze Apigee hybrid che consentono alle richieste HTTP/2 di raggiungere Apigee Ingress. I clienti devono verificare se i bilanciatori del carico che si trovano davanti agli ingressi ibridi Apigee consentono alle richieste HTTP/2 di raggiungere il servizio Apigee Ingress.

  • Apigee Edge for Private Cloud

    I componenti del router e del server di gestione Edge for Private Cloud sono esposti a internet e possono potenzialmente essere vulnerabili. Sebbene HTTP/2 sia abilitato sulla porta di gestione di altri componenti specifici di Edge di Edge per Private Cloud, nessuno di questi componenti è esposto a internet. Sui componenti non Edge, come Cassandra, Zookeeper e altri, HTTP/2 non è abilitato. Ti consigliamo di seguire i passaggi descritti nella sezione Problemi noti di Edge for Private Cloud per risolvere la vulnerabilità di Edge for Private Cloud.

Prodotti non interessati

  • Apigee X

    Le istanze di Apigee X a cui si accede solo tramite Google Cloud i bilanciatori del carico delle applicazioni (livello 7) non sono interessate. Sono inclusi i deployment in cui HTTP/2 è abilitato per i proxy gRPC.

  • Google Cloud API Gateway

    Google Cloud API Gateway non è interessato.

  • Apigee Edge Cloud

    Apigee Edge Cloud non è interessato da questa vulnerabilità.

Che cosa devo fare?

  • Apigee X

    Aggiornamento del 3 novembre 2023:la vulnerabilità è stata risolta tramite l'aggiornamento delle istanze Apigee X rilasciato il 13 ottobre 2023. Per informazioni dettagliate, consulta le note di rilascio.

  • Apigee hybrid

    I clienti di Apigee hybrid dovranno eseguire l'upgrade a una delle seguenti versioni patch:

  • Apigee Edge for Private Cloud

    Gli utenti di Apigee Edge for Private Cloud possono seguire le istruzioni pubblicate in Problemi noti di Edge for Private Cloud per la disattivazione esplicita di HTTP/2 per i componenti esposti.

Quali vulnerabilità vengono affrontate da queste patch?

La vulnerabilità, CVE-2023-44487, potrebbe causare un attacco DoS alla funzionalità di gestione delle API Apigee.

Alta CVE-2023-44487