graphql

GitLab Inc. heeft kwetsbaarheden verholpen in GitLab Community Edition (CE) en Enterprise Edition (EE). De kwetsbaarheden bevinden zich in de GraphQL-implementatie van GitLab. Een eerste kwetsbaarheid maakte het mogelijk voor niet-geauthenticeerde gebruikers om via een GraphQL-directive ongeautoriseerde wijzigingen of verwijderingen uit te voeren op publieke projecten en gebruikersdata. Een tweede kwetsbaarheid stelde niet-geauthenticeerde gebruikers in staat om mutaties uit te voeren via GET-requests door onjuiste validatie van GraphQL multiplex queries, waarbij mutatie-operaties niet correct werden beperkt. Hierdoor kunnen onbevoegden ongeautoriseerde wijzigingen aanbrengen in de staat van de server. Update: Inmiddels is er publieke PoC code beschikbaar waardoor de kans op actief misbruik aanzienlijk toeneemt. Het NCSC adviseert voor systemen waar dit nog niet gebeurt is zo snel mogelijk de updates door te voeren.

GitLab has released security updates to address a critical vulnerability impacting its Community Edition (CE) and Enterprise Edition (EE) software that, under certain conditions, could allow an unauthenticated attacker to remotely modify or delete public projects and user data. The flaw, tracked as CVE-2026-19478, has been rated Critical by GitLab and assigned a CVSS score of 9.4. Released on August 17, 2026, the critical patch release arrived outside the company's usual schedule of twice-monthly updates on the second and fourth Wednesdays, five days after a routine patch release that carried no critical-rated issues. Only self-managed installations need to act. The fixes are available in GitLab 19.2.4, 19.1.6, 19.0.8, and 18.11.11. "GitLab.com and GitLab Dedicated are already running the patched version. GitLab.com and GitLab Dedicated customers do not need to take action," the company said. The following versions are affected - All versions from 18.2 before 18.11.11 19.0 before 19.0.8 19.1 before 19.1.6 19.2 before 19.2.4 The fixes do not extend to the 18.2 through 18.10 branches, which fall inside the affected range. "GitLab has remediated an issue that under certain conditions could allow an unauthenticated user to remotely modify or delete public projects and user data via a GraphQL directive," GitLab said. The CVSS vector published for the flaw indicates that it can be exploited over a network by an attacker holding no credentials, and without any action on the part of a victim. GitLab has not named the GraphQL directive involved or specified what the conditions necessary for exploitation are. The advisory discloses no exploitation of either flaw, and no public exploit code for them has surfaced on GitHub as of August 18, 2026. The second issue fixed in the release, CVE-2026-19650, has been rated High by GitLab with a CVSS score of 7.1, and concerns a cross-site request forgery (CSRF) weakness in the GraphQL multiplex query handler. Unlike the critical flaw, it requires user interaction to work. "GitLab has remediated an issue that under certain conditions could have allowed an unauthenticated user to execute mutations via GET requests due to improper request validation in GraphQL multiplex query handling," the company said. The company said the update introduces no new migrations and is not expected to require downtime on multi-node deployments. The disclosure follows a July 2026 report in which researchers published working exploit code for a separate GitLab flaw affecting self-managed servers. GitLab did not immediately respond to a request for comment. The company said it makes the issues detailing each vulnerability public on its issue tracker 90 days after the release that patched them. GitLab's June 10, 2026 patch release put that window at 30 days. That places technical details of both flaws at around mid-November 2026.

GitLab heeft meerdere kwetsbaarheden verholpen in GitLab Enterprise Edition (EE) en Community Edition (CE) versies variërend van 12.0 tot en met 19.2.2. De kwetsbaarheden betreffen verschillende aspecten van GitLab, waaronder onjuiste privilege-toewijzing waarbij gebruikers met een pending lidmaatschapsstatus onbedoeld permissies konden erven van custom rollen. Verder zijn er problemen met ontbrekende autorisatiecontroles op API-endpoints, waardoor gebruikers met ontwikkelaarsrollen toegang konden krijgen tot externe statuscheckconfiguraties en beperkte merge request informatie van private projecten. Er is ook een Denial-of-Service mogelijk door onjuiste inputvalidatie, en cross-site scripting (XSS) kwetsbaarheden in de analytics dashboard component door onvoldoende sanitisatie van gebruikersinvoer. Daarnaast konden gebruikers met lagere rechten bepaalde package registry metadata wijzigen en CI/CD pipelines op beschermde branches triggeren zonder de juiste permissies. Er waren ook autorisatieproblemen die het mogelijk maakten om project- en groepsinstellingen ongeautoriseerd te wijzigen, en een GraphQL query die toegang gaf tot beleidsconfiguraties van niet-toegestane namespaces. Ten slotte was er een probleem met onjuiste autorisatie van identiteitinformatie, wat leidde tot verkeerde toewijzing van AI-gebruik aan andere namespaces. Deze kwetsbaarheden kunnen leiden tot ongeautoriseerde toegang, wijziging van gegevens, privilege-escalatie, en verstoring van de beschikbaarheid binnen de GitLab Enterprise Edition omgeving.

Risolta vulnerabilità nella libreria Neo4j GraphQL Alert AL06/260807/CSIRT-ITA Sintesi Risolta una vulnerabilità con gravità “alta” presente nella libreria Neo4J GraphQL, libreria che collega GraphQL a Neo4j, permettendo di definire uno schema GraphQL e generare automaticamente query e operazioni CRUD sul database a grafo. Tipologia Authentication Bypass Information Disclosure Security Restrictions Bypass Spoofing Prodotti e versioni affette Neo4j GraphQL 7.x.x, versioni precedenti alla 7.5.6 6.x.x, tutte le versioni versioni precedeenti alla 5.12.14 N.B. Si evidenzia che per tutte le versioni 6.x.x., il vendor non rilascerà alcun workaround e/o patch considerata la data di fine supporto (EOL). Azioni di mitigazione In linea con le dichiarazioni del vendor, si raccomanda di aggiornare i prodotti vulnerabili seguendo le indicazioni del bollettino di sicurezza riportato nella sezione Riferimenti.

Il lock-in tecnologico è la condizione in cui un’organizzazione diventa così dipendente da un vendor specifico – per ragioni tecniche, contrattuali, operative o normative – da rendere la transizione verso un’alternativa eccessivamente costosa, rischiosa o temporalmente impraticabile. Non è, di per sé, una patologia in quanto un certo grado di dipendenza dai propri fornitori è fisiologico in qualsiasi ecosistema tecnologico complesso. Semmai, il problema emerge quando questa stessa dipendenza raggiunge un livello tale da compromettere la capacità dell’organizzazione di prendere decisioni autonome sul proprio stack IT, di rispondere a variazioni del mercato o di gestire una crisi del fornitore senza subire interruzioni operative significative. Indice degli argomenti Nel contesto della cyber security, il lock-in tecnologico introduce una dimensione di rischio specifica che va oltre la semplice dipendenza commerciale. Un’organizzazione profondamente dipendente da un singolo vendor per funzioni di sicurezza critiche, come possono essere un EDR, un SIEM o una piattaforma di identity management, è esposta a un rischio che combina la concentrazione operativa con la superficie di attacco: se quel vendor viene compromesso (come nel caso CrowdStrike del 2024), non solo il servizio si interrompe, ma il sistema di difesa stesso diventa il vettore del problema. Dunque, la diversificazione non è solo una scelta commerciale ma una misura di resilienza. Per i soggetti NIS2 e DORA, il rischio di lock-in ha una dimensione normativa esplicita: DORA identifica la concentrazione verso un singolo provider ICT come rischio sistemico da presidiare e impone alle entità finanziarie di valutare e documentare le dipendenze critiche. NIS2, più in generale, richiede che le misure di sicurezza includano la continuità operativa, un obiettivo difficilmente raggiungibile in presenza di dipendenze non presidiate da adeguate strategie di uscita. La pianificazione della reversibilità non è, quindi, un’opzione avanzata per le organizzazioni più mature: è un requisito di governance che le normative stanno progressivamente rendendo obbligatorio. Quando si parla di forniture IT si possono quindi identificare quattro differenti forme di lock-in tecnologico Il lock-in contrattuale è la forma più immediata e, paradossalmente, la più facilmente prevenibile se affrontata nella fase di negoziazione. Si manifesta attraverso clausole che rendono la cessazione del rapporto commerciale eccessivamente onerosa: penali di uscita anticipata calcolate sull’intero valore residuo del contratto, rinnovi automatici con finestre di disdetta strette, limitazioni al diritto di portabilità dei dati, periodi minimi contrattuali pluriennali senza clausole di revisione. Nei contratti con i grandi hyperscaler e con i vendor di software Enterprise, queste clausole sono spesso la norma, non l’eccezione. La difesa contrattuale contro questo tipo di lock-in richiede attenzione in fase di negoziazione: clausole di exit esplicite con termini e costi predefiniti; diritto di portabilità dei dati in formato standard senza costi aggiuntivi; finestre di disdetta ragionevoli (90 giorni è uno standard accettabile per la maggior parte dei servizi); limitazione delle penali di uscita anticipata a importi proporzionati e non punitivi. Per i contratti con vendor che gestiscono funzioni critiche, è opportuno negoziare anche obblighi di supporto alla transizione: un periodo di affiancamento post-contratto durante il quale il vendor fornisce accesso ai dati e supporto tecnico alla migrazione. Il lock-in tecnico è la forma più pervasiva e difficile da rimuovere una volta instauratasi. Si manifesta attraverso la dipendenza da formati proprietari (e quindi, dati che non possono essere esportati in formati standard senza perdita di informazioni o senza strumenti specifici del vendor) e da API proprietarie che richiedono riscrittura significativa delle integrazioni per migrare verso un’alternativa. Un CRM che archivia i dati in un formato interno non esportabile in CSV o JSON standard, un SIEM che produce log in un formato proprietario non leggibile da altri strumenti, una piattaforma cloud che offre servizi managed senza equivalenti standard: questi sono esempi concreti di lock-in tecnico che si accumula silenziosamente nel tempo, spesso senza che l’organizzazione ne sia consapevole fino al momento in cui cerca di uscire. La prevenzione del lock-in tecnico richiede una strategia di architettura deliberata: privilegiare standard aperti e interoperabili nelle scelte tecnologiche, evitare dipendenze da servizi proprietari privi di alternative equivalenti, mantenere layer di astrazione (API gateway, middleware) che isolino il business logic dalle specificità del vendor sottostante. Per le piattaforme cloud, l’adozione di strumenti di Infrastructure as Code (Terraform, Pulumi) con provider-agnostic configuration riduce significativamente il costo di una eventuale migrazione verso un hyperscaler alternativo. Il lock-in operativo è il meno visibile dei quattro e spesso il più costoso da risolvere. Si accumula nel tempo attraverso la specializzazione del personale su tecnologie proprietarie specifiche: team IT che conoscono profondamente una piattaforma ma non hanno esperienza con le alternative, processi operativi costruiti attorno alle specificità di un vendor, procedure di troubleshooting e documentazione che assumono implicitamente la presenza di quel vendor. Quando l’organizzazione deve cambiare, si trova a dover affrontare non solo la migrazione tecnica, ma anche un gap di competenze che richiede tempo e risorse significative per essere colmato. La gestione del lock-in operativo richiede un approccio proattivo alla formazione e alla documentazione: mantenere competenze interne che non dipendano esclusivamente da un singolo vendor; costruire processi operativi che siano il più possibile vendor-agnostic; documentare le configurazioni e le procedure in modo da renderle trasferibili. Per le competenze critiche, è buona pratica mantenere almeno una risorsa interna con conoscenza dell’alternativa principale, anche se non la si utilizza attivamente, per garantire la capacità di valutazione in caso di necessità di transizione. Il lock-in normativo è una categoria specifica dei settori regolamentati: si verifica quando la scelta di un vendor crea dipendenze che sono difficili da sciogliere per ragioni di conformità. Un sistema di archiviazione che garantisce la conservazione dei log per 10 anni secondo requisiti normativi specifici, una piattaforma di firma elettronica certificata secondo standard nazionali, un sistema di gestione dei dati sanitari conforme a requisiti specifici di settore: migrare da questi sistemi richiede non solo la migrazione tecnica dei dati, ma la verifica che il nuovo vendor garantisca la stessa conformità normativa, spesso un processo lungo e costoso. Per le organizzazioni nei settori critici NIS2, il lock-in normativo può manifestarsi anche attraverso la data residency: un vendor che garantisce la residenza dei dati in specifiche regioni geografiche richieste dalla normativa applicabile crea una dipendenza che limita le alternative disponibili. La prevenzione richiede di verificare, in fase di selezione, che esistano almeno due vendor alternativi in grado di soddisfare i requisiti normativi applicabili — non uno solo. Riconoscere il lock-in è necessario, ma non sufficiente: per prendere decisioni informate, l’organizzazione ha bisogno di uno strumento che consenta di misurarlo in modo coerente e comparabile tra vendor diversi. Il Vendor Dependency Index (VDI) è un framework di valutazione strutturato in sei dimensioni, ciascuna con un peso relativo proporzionale al suo impatto sulla capacità di transizione. Il risultato è un punteggio da 1 (dipendenza minima, transizione agevole) a 5 (lock-in critico, transizione estremamente costosa o impraticabile nel breve termine). Il VDI non è uno strumento assoluto, ma uno strumento di confronto e prioritizzazione. Il suo valore principale è rendere visibile e quantificabile un rischio che altrimenti rimane implicito nelle valutazioni soggettive dei team IT. Un VDI superiore a 3,5 per un vendor che gestisce funzioni critiche deve attivare un piano di mitigazione; un VDI superiore a 4,5 rappresenta una dipendenza che richiede attenzione immediata del management. La pianificazione della reversibilità è spesso percepita come un esercizio accademico, utile in teoria ma difficilmente necessario nella pratica quotidiana. Gli scenari di crisi che seguono hanno lo scopo di ancorare questa percezione alla realtà: sono casi che si sono verificati, si verificano regolarmente, e che le organizzazioni prive di una exit strategy hanno affrontato in condizioni di estrema difficoltà operativa. Un vendor IT che gestisce infrastrutture critiche entra in procedura fallimentare. Il servizio si interrompe con preavviso di 30-60 giorni. I dati sono bloccati fino alla nomina del curatore. L’organizzazione deve migrare in emergenza verso un’alternativa senza il supporto del vendor. Casi reali: il fallimento di diversi provider cloud di secondo livello negli anni 2015-2020 ha lasciato centinaia di clienti senza accesso ai propri dati per settimane. La lezione: la solidità finanziaria del vendor è un elemento del rischio lock-in, non solo un indicatore commerciale. Un VDI elevato su un vendor con indicatori finanziari in deterioramento è un segnale di allerta critico. Un vendor critico viene acquisito da un concorrente diretto dell’organizzazione cliente, o da un soggetto con interessi in conflitto. Il nuovo proprietario modifica le condizioni contrattuali, aumenta i prezzi in modo significativo, o discontinua il prodotto. L’organizzazione si trova vincolata a un contratto con un vendor che non avrebbe mai scelto. Casi reali: l’acquisizione di VMware da parte di Broadcom (2023) e la successiva ristrutturazione delle licenze ha costretto migliaia di organizzazioni a rivalutare la propria dipendenza dalla piattaforma di virtualizzazione, con costi di migrazione non previsti. La lezione: il vendor che si acquista oggi potrebbe non essere lo stesso tra due anni. Un vendor viene sanzionato da un’autorità regolatoria (ACN, Garante privacy, autorità di vigilanza finanziaria) o incluso in liste di restrizione per ragioni di sicurezza nazionale. L’organizzazione deve cessare il rapporto entro tempi imposti dalla normativa, indipendentemente dal costo e dalla complessità della migrazione. Casi reali: le restrizioni imposte in diversi paesi europei e negli USA a vendor di telecomunicazioni e software di origine cinese (Huawei, ZTE, Kaspersky) hanno costretto le organizzazioni nei settori critici a migrazioni urgenti. La lezione che ne possiamo trarre è che il rischio geopolitico è un componente del rischio lock-in che deve essere valutato esplicitamente per i vendor con sede o interessi in paesi ad alto rischio. Sviluppare un piano di transizione verso provider alternativi evita l’interruzione operativa del business in caso di crisi del fornitore. La pianificazione della reversibilità è un pilastro del Vendor Risk Management moderno per mitigare i rischi cyber: la capacità di uscire da una relazione con un vendor critico in tempi ragionevoli e senza interruzioni operative non è una misura difensiva straordinaria, ma un requisito di resilienza che le normative NIS2 e DORA stanno progressivamente codificando. La reversibilità non significa necessariamente cambiare vendor frequentemente o mantenere architetture ridondanti costose: significa avere la capacità di farlo quando necessario, in tempi accettabili, con un costo proporzionato. Questa capacità si costruisce nel tempo attraverso scelte architetturali deliberate, clausole contrattuali adeguate e un monitoraggio continuo del grado di dipendenza. Un’organizzazione che ha investito nella portabilità dei dati, nell’interoperabilità dei sistemi e nella formazione del personale su più piattaforme è intrinsecamente più resiliente e più conforme ai requisiti normativi di una che ha ottimizzato esclusivamente sull’integrazione con un singolo vendor. La portabilità dei dati è il prerequisito tecnico di qualsiasi strategia di exit. Senza la capacità di estrarre i propri dati in formato standard e completo, qualsiasi piano di migrazione è teorico. Eppure, nella pratica, molte organizzazioni scoprono i limiti alla portabilità dei dati solo quando tentano di effettuare la migrazione: formati di esportazione incompleti, API con rate limit che rendono l’estrazione di grandi volumi impraticabile in tempi ragionevoli, costi di egress per il trasferimento dei dati fuori dalla piattaforma del vendor. La difesa contro questo rischio deve essere contrattuale e tecnica insieme. Sul piano contrattuale: clausole esplicite che garantiscono l’esportazione completa dei dati in formati aperti e documentati, senza costi aggiuntivi, entro termini definiti dalla richiesta di cessazione. Sul piano tecnico: test periodici di esportazione dei dati critici (non solo la verifica che la funzione esista, ma la verifica che funzioni correttamente con i volumi reali) e documentazione aggiornata del formato dei dati esportati per facilitare l’importazione nel sistema del vendor alternativo. L’adozione di standard aperti e di architetture interoperabili è la strategia di prevenzione del lock-in tecnico più efficace a lungo termine. Nel contesto cloud, questo si traduce nella preferenza per servizi che implementano API standard (REST, OpenAPI, GraphQL) rispetto a API proprietarie, nell’utilizzo di formati di dati aperti (JSON, Parquet, CSV) rispetto a formati binari proprietari, e nell’adozione di strumenti di orchestrazione e provisioning che supportano nativamente più provider (Kubernetes per i container, Terraform per l’Infrastructure as Code). Per le piattaforme di sicurezza, l’interoperabilità è garantita dall’adozione di standard come STIX/TAXII per la condivisione di threat intelligence, OpenC2 per l’automazione della risposta, e OCSF (Open Cybersecurity Schema Framework) per la normalizzazione dei log di sicurezza. L’adozione di questi standard non è solo una scelta tecnica: è una misura di resilienza che riduce il costo di sostituzione di un componente della stack di sicurezza e facilita l’integrazione con nuovi vendor. La strategia multi-vendor, ossia distribuire le funzioni critiche tra vendor diversi per ridurre la concentrazione del rischio, è la risposta più diretta al lock-in tecnologico, ma anche quella con i costi operativi più elevati. Gestire più vendor per la stessa funzione introduce complessità: interfacce diverse, procedure operative distinte, costi di formazione moltiplicati, potenziali problemi di integrazione. La scelta tra vendor singolo e multi-vendor non è quindi una scelta tra sicurezza e comodità: è una valutazione del trade-off tra rischio di concentrazione e costo operativo della diversificazione. Un approccio pragmatico prevede di applicare la strategia multi-vendor selettivamente, in funzione della criticità della funzione e del VDI del vendor primario: per le funzioni essenziali con VDI elevato, la duplicazione è giustificata e raccomandabile; per le funzioni con VDI basso e alternative disponibili in tempi ragionevoli, la complessità aggiuntiva di un secondo vendor non è necessariamente giustificata. Il caso degli hyperscaler è emblematico: una strategia multi-cloud attiva (workload distribuiti tra AWS, Azure e GCP) riduce il lock-in ma aumenta significativamente la complessità operativa; una strategia cloud-agnostic basata su Kubernetes e Terraform mantiene la portabilità senza la complessità della gestione multi-cloud attiva. La exit strategy inizia dal contratto. Le clausole di reversibilità, spesso trascurate nella negoziazione, quando l’attenzione è concentrata sulla funzionalità e sul prezzo, sono lo strumento che garantisce all’organizzazione il diritto e la capacità pratica di uscire dalla relazione con il vendor in condizioni controllate. Gli elementi essenziali di una clausola di reversibilità efficace coprono quattro aree: il diritto di portabilità (esportazione completa dei dati in formato standard, senza costi aggiuntivi); il supporto alla transizione (periodo di affiancamento post-contratto, tipicamente 90-180 giorni, durante il quale il vendor continua a fornire accesso ai dati e supporto tecnico alla migrazione); la cancellazione certificata (distruzione sicura dei dati residui con certificazione documentata); la continuità del servizio (garanzia che il servizio continui a funzionare normalmente durante il periodo di transizione, senza degradazione delle performance o delle funzionalità). Il piano di migrazione è il documento operativo che traduce la strategia di exit in un progetto concreto con fasi, responsabilità, risorse e tempistiche. Deve essere preparato con anticipo: idealmente al momento dell’onboarding del vendor, non quando la migrazione diventa urgente, e aggiornato periodicamente per riflettere l’evoluzione dell’ambiente tecnologico e della relazione con il vendor. Un piano di migrazione mai aggiornato è quasi inutile nel momento del bisogno. Le fasi tipiche di un piano di migrazione da un vendor critico sono: assessment dell’ambiente attuale (inventario di dati, integrazioni, dipendenze, competenze); selezione del vendor alternativo (con processo di valutazione formale che include security assessment e VDI preliminare); progettazione dell’architettura target; migrazione pilota su ambiente non produttivo; migrazione progressiva degli ambienti produttivi con rollback plan; verifica funzionale e di sicurezza; dismissione dell’ambiente del vendor precedente con cancellazione certificata dei dati. Per i sistemi critici, la fase di coesistenza in cui entrambi i vendor operano in parallelo è raccomandata anche quando aumenta il costo a breve termine: garantisce la continuità operativa durante la transizione e riduce il rischio di interruzione. Il lock-in nei servizi cloud degli hyperscaler (AWS, Microsoft Azure, Google Cloud Platform) merita una trattazione specifica per la sua pervasività e per la complessità delle dipendenze che può generare. I grandi provider cloud offrono ecosistemi di servizi managed estremamente ricchi e integrati: database proprietari (DynamoDB, Cosmos DB, BigQuery), servizi serverless (Lambda, Azure Functions, Cloud Run), strumenti di ML/AI nativi, servizi di sicurezza integrati. L’adozione di questi servizi genera produttività immediata e integrazione nativa e il lock-in tecnico che cresce con ogni servizio managed aggiuntivo adottato. La risposta non è evitare i servizi managed degli hyperscaler, sarebbe come rinunciare a vantaggi competitivi reali, ma adottarli con consapevolezza del lock-in che generano. Una strategia cloud pragmatica distingue tra i servizi che sono accettabile avere in lock-in (servizi non critici, facilmente riproducibili, con basso VDI) e quelli per cui la portabilità deve essere preservata (dati critici, funzioni essenziali, sistemi con compliance normativa specifica). Per questi ultimi, l’investimento in architetture cloud-agnostic (container-based, IaC-managed, con storage in formati aperti) è un investimento in resilienza, non solo in flessibilità tecnica. Per le organizzazioni che operano in ambienti ibridi (infrastruttura on-premise combinata con servizi cloud) il rischio di lock-in si manifesta anche attraverso la dipendenza dagli strumenti di gestione dell’ambiente ibrido stesso: soluzioni come VMware (ora Broadcom), Azure Arc, AWS Outposts. L’acquisizione di VMware da parte di Broadcom e la conseguente ristrutturazione del modello di licensing è diventata il caso di scuola del lock-in negli ambienti ibridi: migliaia di organizzazioni si sono trovate a dover rivalutare la propria infrastruttura di virtualizzazione in condizioni di urgenza, con costi non previsti e alternative tecnicamente complesse da implementare in tempi brevi.

GitLab Inc. heeft meerdere kwetsbaarheden verholpen in GitLab Community Edition en Enterprise Edition, specifiek in versies variërend van 9.2 tot voor 18.11.1, inclusief diverse 18.x releases. De kwetsbaarheden betreffen verschillende componenten van GitLab, waaronder de discussions endpoint, GraphQL API, note retrieval, issue import, Mermaid sandbox, Storybook development environment, issue rendering, web interface en Virtual Registries. Geauthenticeerde gebruikers kunnen door onvoldoende resource limits of onjuiste inputvalidatie resource-exhaustie veroorzaken, wat leidt tot Denial-of-Service. Daarnaast zijn er problemen met onjuiste autorisatiecontroles waardoor project owners group fork preventie kunnen omzeilen, en met onvoldoende CSRF-bescherming waardoor ongeauthenticeerde gebruikers GraphQL mutaties kunnen uitvoeren. Verder is er een cross-site scripting (XSS) kwetsbaarheid die ongeauthenticeerde gebruikers toestaat om JavaScript code in de browser van een gebruiker uit te voeren. Ook kunnen gebruikers door onjuiste toegangscontrole de titels van vertrouwelijke issues in publieke projecten inzien en toegang krijgen tot Virtual Registries via onjuist gescopeerde credentials. Sommige kwetsbaarheden maken het mogelijk om ongeautoriseerde content te injecteren in browser sessies van andere gebruikers. De kwetsbaarheden zijn aanwezig in meerdere opeenvolgende versies en betreffen zowel Community als Enterprise edities van GitLab.

New attack waves from the ‘PhantomRaven’ supply-chain campaign are hitting the npm registry, with dozens of malicious packages that exfiltrate sensitive data from JavaScript developers. The campaign was initially uncovered in October 2025 by researchers at cybersecurity company Koi, who said that it had been running since August and published 126 malicious packages on the npm platform. Application security company Endor Labs found three additional waves of the PhantomRaven attack that occurred between November 2025 and February 2026 and distributed 88 packages via 50 disposable accounts. In most cases, the threat actor used 'slopsquatting' to mimic established projects like Babel and GraphQL Codegen. They published malicious packages under names that appear suggested by large-language models (LLMs). According to Endor Labs, 81 of the malicious PhantomRaven packages are still available in the npm registry. PhantomRaven uses a detection evasion technique called Remote Dynamic Dependencies (RDD), where the metadata file 'package.json' specifies a dependency at an external URL. This way, the threat actor does not need to embed malicious code in the package, bypassing automated inspection. When an unsuspecting developer runs ‘npm install,’ the dependency containing the malware is automatically downloaded from the attacker's server and executed. According to Endor Labs' research, the malware will collect various sensitive information from the compromised machine, like emails from .gitconfig, .npmrc, and environment variables. CI/CD tokens from GitHub, GitLab, Jenkins, and CircleCI platforms are also targeted The researchers say that the malware also harvests system information, such as IP, hostname, operating system, and Node version, to fingerprint the machine. In the final stage, the malicious package exfiltrates the stolen data to the attacker’s command-and-control (C2) server. Usually, this action is done via an HTTP GET request, but HTTP POST and WebSocket are also used for redundancy. Endor Labs has noticed that the infrastructure remains consistent across all four observed waves of the PhantomRaven campaign, with domains containing the word 'artifact' that are hosted on Amazon Elastic Compute Cloud (EC2) and lack a TLS certificate. The payload was also nearly identical across all waves, with 257 of the 259 lines of code remaining unchanged. However, the attackers evolved operationally, rotating npm and email accounts, changing npm package metadata, and modifying PHP endpoints. Also, they published more frequently in the more recent attacks, with four packages added in a single day, on February 18. Despite lacking sophistication, the PhantomRaven campaign is ongoing and relying on the same technique, infrastructure patterns, and payload structure. With just minimum modifications for domains, endpoints, npm accounts, and dependency names, the threat actor managed to stay operational. To protect against this threat, developers are recommended to verify the legitimacy of their building blocks, only use packages from reputable publishers, and avoid copy-pasting suggestions from AI chatbots or unvetted sources. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

Salesforce is warning customers that hackers are targeting websites with misconfigured Experience Cloud platforms that give guest users access to more data than intended. However, the ShinyHunters extortion gang claims to be actively exploiting a new bug to steal data from instances. Salesforce has shared guidance for its customers to defend against hackers actively targeting the /s/sfsites/aura API endpoint on misconfigured Experience Cloud instances that gives guest users access to more data than intended. The company states that attackers are deploying a modified version of AuraInspector, an open-source auditing tool developed by Mandiant, which can help administrators identify access control misconfigurations within the Salesforce Aura framework. "It is important to note that Salesforce remains secure, and this issue is not due to any vulnerability inherent to our platform. Our investigation to date confirms that this activity relates to a customer-configured guest user setting, not a platform security flaw," Salesforce says in the advisory. The company explains that a publicly exposed Salesforce Experience site accepts a "guest user profile" to provide anonymous, unauthenticated visitors with access to data intended to be public. If the profile is misconfigured and has excessive permissions, visitors can "directly query Salesforce CRM objects without logging in." Salesforce says an organization can improve its defenses against such attacks by auditing guest user permissions and adopting the principle of least privilege. The vendor says the highest-impact change customers can make to mitigate the risk is to disable guest access to public APIs and remove the API Enabled setting from the guest profile. The company recommends customers take the following set of immediate actions: Audit guest user permissions and reduce them to the minimum required. Set org-wide defaults to Private for external access. Turn off Portal User Visibility and Site User Visibility so guest users cannot enumerate internal users. Disable self-registration unless it is truly needed, because exposed guest data could be used to create portal accounts and expand access. System administrators should also review Aura Event Monitoring logs for unusual access patterns, unfamiliar IP addresses, or queries against objects that should not be public, and designate a Security Contact so Salesforce can notify the right person quickly. ShinyHunters takes responsibility In a post on their data leak site, the ShinyHunters threat actor has claimed responsibility for the Salesforce Aura/Experience Cloud data theft attacks. Mandiant Consulting confirmed in a statement for BleepingComputer that hackers are using AuraInspector in attempts to breach companies. "We are aware of a threat actor attempting to facilitate intrusions by misusing the AuraInspector open-source tool to automate vulnerability scans across Salesforce environments," said Charles Carmakal, Mandiant chief technology officer. "We are working closely with Salesforce and our customers to provide the necessary telemetry and detection rules to mitigate potential risk. It is important to note that detecting scanning activity in an organization’s logs does not indicate a compromise," the CTO said. ShinyHunters says that they compromised around 100 high-profile companies, many of them in the cybersecurity sector. The total count of breached organizations is somewhere between 300 and 400, the hackers told BleepingComputer. The hackers told BleepingComputer that in September 2025, they started to compromise companies with insecure Experience Cloud access control configurations for guest users. They were also identifying Aura instances by scanning the internet for the /s/sfsites/ endpoint. Due to a limitation from Salesforce, the threat actor said that they could only query 2,000 records at a time through the company's GraphQL API, which slowed the data theft process. However, the hacker found the sortBy parameter, which they claim bypassed the restriction. When AuraInspector was released in January to help admins find misconfigured instances, ShinyHunters says they modified the code for additional reconnaissance. Salesforce's advisory confirms that the threat actor's variant of Mandiant's tool was used "to perform mass scanning of public-facing Experience Cloud sites." The threat actors then created their own tool to steal data, which BleepingComputer has learned uses the following string as part of its user agent: Anthropic/RapeForceV2.01.39 (AGENTIC) This tool has a similar name to the "RapeFlake" tool used during the SnowFlake data theft attacks. ShinyHunters claims that after Salesforce fixed the sortBy trick previously noted by Mandiant, they discovered a new method to bypass the 2,000 record query restriction, "and have been exploiting it since discreetly." The threat actor claims that Salesforce fixed the method used to bypass the 2,000-record limit over the weekend before releasing the advisory, but says they have since discovered a vulnerability that allows data theft from Aura instances even when they are properly configured. BleepingComputer has not been able to independently confirm if this is true. We contacted Salesforce about this allegedly new attack, but the company continues to state that there is no vulnerability in its platform. The threat actor told BleepingComputer that they believe disabling "Public Access" to an instance will protect Salesforce customers against this new attack. However, doing so will also disable guest access and turn the website into a private portal. The threat actor told BleepingComputer that the new attacks are using the following user agent, which looks like a normal browser user agent. Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 Chrome/120.0.0.0 Safari/537.36 Surprisingly, the threat actor told BleepingComputer that they believe that Salesforce customers can protect themselves from these attacks by disabling "Public Access" to an instance. However, doing so will also disable guest access and turn the website into a private portal. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report

GitLab heeft kwetsbaarheden verholpen in GitLab CE/EE. De kwetsbaarheden omvatten verschillende problemen, waaronder de mogelijkheid voor geauthenticeerde gebruikers om externe API-aanroepen te misbruiken, wat kan leiden tot een Denial-of-Service. Daarnaast konden geauthenticeerde gebruikers via GraphQL ongeautoriseerde wijzigingen aanbrengen in projectconfiguraties en AI-instellingen van ongeautoriseerde namespaces. Een andere kwetsbaarheid stelde ongeauthenticeerde gebruikers in staat om willekeurige code uit te voeren in de browser van een geauthenticeerde gebruiker via een kwaadaardige webpagina. Bovendien konden geauthenticeerde gebruikers gevoelige informatie lekken door speciaal vervaardigde afbeeldingen te gebruiken die de bescherming van de asset proxy omzeilden. Ten slotte was er een kwetsbaarheid die het mogelijk maakte om opgeslagen cross-site scripting (XSS) uit te voeren via GitLab Flavored Markdown, wat de beveiliging van de applicatie in gevaar kon brengen.

GitLab heeft kwetsbaarheden verholpen in GitLab Community Edition (CE) en Enterprise Edition (EE) versies. De kwetsbaarheden omvatten de mogelijkheid voor ongeauthenticeerde aanvallers om Denial-of-Service condities te veroorzaken door speciaal samengestelde payloads en GraphQL verzoeken te versturen. Daarnaast konden geauthenticeerde aanvallers ongeautoriseerde pipeline-acties uitvoeren door commits te wijzigen en ongeautoriseerde toegang tot projecten verkrijgen via het goedkeuringsproces van toegang aanvragen. Deze kwetsbaarheden kunnen de integriteit en beschikbaarheid van de systemen in gevaar brengen.

It might surprise some that a security company would choose WordPress as the backbone of its digital content operations. After all, WordPress is often associated with open-source plugins, community themes, and a wide range of deployment practices—some stronger than others. But that perception overlooks what modern WordPress can deliver when it’s architected, operated, and governed with discipline. In our Digital Experience Platform (DXP) at Malwarebytes, WordPress serves as the content layer—an editorial hub that feeds multiple customer experiences. The reason is pragmatic and security-forward. WordPress offers transparency (open code and ecosystem), control (self-hosted in our environment, with strict governance), and maturity (a seasoned core with an established security model). Combined with a decoupled architecture, strong identity and access controls, rigorous supply chain management, and a hardened infrastructure, WordPress becomes an ideal content engine for an enterprise-grade, security-first DXP within an enterprise-grade MarTech stack. DXP vision and the role of WordPress When we say DXP, we mean the orchestration layer that brings together content, personalization, analytics, experimentation, commerce, support experiences, and more. It’s not a single product; it’s the way we coordinate systems to deliver cohesive customer journeys across web, mobile, and product surfaces. In that model, WordPress is our content authoring hub. Editors draft, review, and publish content once; APIs then power multiple front-ends—websites built with Next.js/React, mobile applications, and support portals. This headless pattern decouples the authoring experience from delivery. Why decouple? By delivering both static and server-side rendered (SSR) pages directly from the edge, we meet aggressive latency goals and excel in Core Web Vitals scores on a global scale. This approach ensures content is as close as possible to end users, providing consistently fast load times regardless of location. Our architecture isolates site performance from backend processes, meaning bursts of traffic or complex deployments don’t degrade the visitor experience. Security isolation is equally foundational to our platform design. The public-facing runtime never exposes the WordPress admin interface or control endpoints—instead, these administrative components reside securely behind private networking, protected by robust access controls and authentication. This segmentation shields both business-critical operations and sensitive data, lowering the attack surface and reducing risk without impeding editors or developers. This architecture also boosts development velocity. Front-end engineers can iterate rapidly, independently releasing new features or improvements without being bottlenecked by backend deployments. At the same time, content editors retain full publishing agility via the headless CMS, able to launch and update site content at will. This parallel, decoupled workflow ensures that technical and editorial teams each operate at their highest efficiency, supporting an environment of continuous innovation and timely content delivery. How speed helps security Rapid and reliable deployments are a cornerstone of our security posture, empowering us to respond quickly to new threats and vulnerabilities. By streamlining and automating our release processes, we can efficiently ship patches and mitigations as soon as issues arise, minimizing the window of exposure. Equally important, our deployment pipelines are built to support safe rollbacks, allowing us to confidently revert any changes that introduce instability or unexpected behavior—maintaining operational continuity no matter how urgent the circumstances. Shortening our development and deployment cycle is not just about speed—it’s one of the most effective security controls we employ. Frequent, predictable deploys mean our systems are always running the latest protections and bug fixes, dramatically reducing the risks associated with outdated code or configurations. This agility ensures we stay ahead of evolving threats, support innovation without sacrificing safety, and adapt to changing requirements with minimal disruption, making security a continuous, integrated aspect of our delivery workflow. Why WordPress aligns with security-first Open-source transparency matters. With WordPress, we can inspect every line of core and plugin code, run our own audits, and make informed decisions about the attack surface. The community’s response to security issues adds resilience through coordinated disclosures, rapid patches, and widely disseminated advisories. The core platform is mature and stable. The WordPress security team has established processes for responsible disclosure and a consistent patch cadence. Operating close to core (and avoiding heavy core modifications) enables us to adopt updates quickly. Finally, talent availability accelerates secure outcomes. A large pool of WordPress developers and security practitioners means faster remediation, effective code reviews, and a healthy ecosystem of best practices and tooling. Architecture that reduces risks Headless/decoupled architecture Our public website leverages the powerful combination of a Content Delivery Network (CDN) and a Web Application Firewall (WAF) to deliver a seamless and secure user experience. By distributing static content across global edge locations, the CDN ensures lightning-fast load times while also enabling server-side rendering at the edge for dynamic content. This hybrid approach allows us to serve both static and server-rendered pages efficiently, providing relevant content with minimal latency. Positioned behind the CDN, the WAF offers an added layer of security by blocking malicious traffic and safeguarding our site from threats, ensuring that both performance and protection are at the forefront of our web infrastructure. To further enhance security and streamline workflows, we utilize single sign-on (SSO) with multi-factor authentication (MFA) for accessing all administrative interfaces and developer endpoints. The WordPress admin area, GraphQL and REST APIs, as well as build hooks, are only accessible through this robust SSO with MFA, ensuring that only authorized team members can reach sensitive controls and data. Access is strictly segmented, treating the admin plane as an internal-only application and fully separating it from the public-facing site. This architecture minimizes risk, protects critical infrastructure, and supports efficient, secure collaboration among our administrative and development teams. Network and edge security Our Web Application Firewall (WAF) works in tandem with advanced bot management to protect our site from a wide range of online threats. The WAF actively filters malicious payloads and prevents exploitation attempts, while the bot management system blocks known bad actors and suspicious automated traffic. Together, they help enforce rate limits—ensuring fair usage and preventing abuse that could impact site performance or security. This layered approach allows us to maintain a reliable, secure environment for all our users while shielding our resources from sophisticated cyber threats. To further secure our infrastructure, we have robust DDoS mitigation controls in place, designed to identify and absorb large-scale volumetric attacks before they reach our application. Coupled with customizable geo-blocking and ASN (Autonomous System Number) policies, we can restrict or filter access from high-risk regions and networks known for hostile activity. This proactive combination not only helps protect against both widespread and targeted attacks, but also ensures the continued availability and performance of our services for legitimate users around the globe. We enforce modern transport security standards across our entire platform by mandating TLS 1.3 for all connections. This ensures data transmitted between users and our site is encrypted using the latest, most secure protocol available. In addition, HTTP Strict Transport Security (HSTS) is enabled, compelling browsers to interact with our site only via secure HTTPS connections. Together, TLS 1.3 and HSTS provide strong guarantees of data integrity, confidentiality, and protection against common interception or downgrade attacks, giving our users peace of mind with every interaction. Service isolation and least privilege Our security framework is built on the principle of least-privilege access, ensuring that databases, object storage, and service accounts are tightly controlled. Each system and user is granted only the permissions essential for their specific role—nothing more. This minimizes the potential impact of accidental or malicious activity, as access is segmented and strictly limited across all layers of our architecture. By aligning permissions closely with functional requirements, we significantly reduce the risk of data exposure or unauthorized operations, reinforcing the integrity and confidentiality of our platform. Hardening at the application layer Secure configuration In our production WordPress environment, we implement a series of stringent measures to protect both the core application and user data. File editing through the wp-admin interface is completely disabled, eliminating a common attack vector and reducing the risk of unauthorized code changes. We enforce the use of strong, unique salts and keys, enhancing the integrity and security of authentication cookies and stored data. Additionally, the core filesystem is kept strictly read-only in production, preventing alterations to critical files and ensuring that even in the event of a compromise, attackers cannot modify system-level code or inject persistent threats. To further reduce the platform’s attack surface, we restrict XML-RPC functionality—often abused for brute-force attacks—and limit exposed REST API endpoints strictly to those required by our headless WordPress clients. User enumeration patterns, which attackers may exploit to gather account names, are actively blocked, thereby safeguarding user identities. On the front end, we enforce robust security headers, including a finely scoped Content Security Policy (CSP) to mitigate XSS threats, strict X-Frame-Options and Frame-Ancestors to prevent clickjacking, X-Content-Type-Options to block MIME-type attacks, and a privacy-friendly Referrer-Policy to minimize information leakage. Together, these layered controls ensure our site remains resilient against a broad spectrum of web threats. Auth and session security We integrate Single Sign-On (SSO) through industry-standard protocols such as SAML and OIDC, streamlining secure access for our teams while reducing the risks associated with password proliferation. Automated user provisioning and deprovisioning are managed via SCIM, ensuring that access is immediately granted to new team members and promptly revoked when it’s no longer needed. MFA is mandatory for all privileged users, significantly strengthening the security of critical accounts and administrative functions, and defending against credential-based attacks. Access within our environment is granted based on granular, role- and capability-based policies. Custom roles are carefully tailored so that editors, contributors, and admins receive only the permissions essential to their responsibilities, minimizing exposure and preventing privilege creep. We further secure administrative access by enforcing short-lived sessions, reducing the window of opportunity for session hijacking or misuse. This approach ensures that even if an administrative session is compromised, the potential for abuse is tightly constrained, keeping our site and its data safe. Data handling Security is at the forefront of our development practices, with a strong emphasis on protecting both our site and its users from application-level threats. We enforce the use of prepared statements for all database queries to defend against SQL injection, mandate thorough output escaping to prevent cross-site scripting (XSS), and ensure rigorous input sanitization in every layer of custom code and approved plugins. For protection against cross-site request forgery (CSRF), we implement nonces, providing an additional safeguard to validate user actions and prevent unauthorized commands. This multifaceted approach applies to every custom solution and trusted extension, reinforcing the reliability and trustworthiness of our platform. Data privacy and compliance round out our security strategy. We are committed to minimizing the storage of personally identifiable information (PII), classifying data sensitivity, and applying data retention policies that align with both regulatory requirements and customer expectations. Consent management is thoughtfully integrated into both our publishing workflow and the front-end user experience, so we can uphold privacy standards without sacrificing usability. This ensures users remain informed and in control of their data—supporting compliance with privacy laws and building trust through transparency and respect for user choices. Plugin and supply chain governance Controlled ecosystem Our approach to plugin management is deliberately conservative, maintaining a strict allowlist to ensure only vetted and essential plugins are present within our environment. We prioritize the use of “must-use” (mu-) plugins for enforcing global policies and delivering critical functionality, as these plugins are always active and centrally managed. This strategy prevents unauthorized or unnecessary code from entering our system, supports consistency across environments, and enables us to embed security controls directly into our platform’s foundational layers. Before any plugin or theme is deployed to production, it undergoes a comprehensive code review process to assess security, performance, and compatibility. We are proactive in curbing plugin sprawl, regularly auditing our stack and removing redundant or unsupported components to minimize complexity and reduce our attack surface. By keeping our codebase lean and disciplined, we not only defend against potential vulnerabilities found in third-party additions but also streamline maintenance and updates, ensuring the long-term stability and security of our production environment. Dependency management We take a comprehensive approach to dependency management and software supply chain integrity by generating Software Bill of Materials (SBOMs) for both PHP and JavaScript codebases. SBOMs allow us to track all direct and transitive dependencies, as well as their associated licenses, ensuring greater visibility and control over the components that make up our application. Dependencies are always pinned and locked to specific, approved versions, reducing the risk of introducing vulnerabilities through unintentional upgrades or changes. Automated tools like Dependabot continuously monitor for updates and propose them, but nothing reaches production unless it successfully passes through our continuous integration (CI) security gates. Our CI/CD pipeline is fortified with robust security controls at every stage. Every update, whether a dependency or code change, triggers automated Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) to identify potential vulnerabilities both before and during runtime. We employ secret scanning to prevent accidental exposure of credentials and keys, and every build is evaluated for license compliance and regulatory conformance. This layered approach ensures that our development processes are secure by default, continually verifying software quality, integrity, and compliance before anything is deployed to production. Vulnerability intelligence and patching We actively monitor CVE feeds and WordPress-focused security advisories, such as WPScan, to stay ahead of emerging vulnerabilities and threats. By keeping a close eye on both general and platform-specific intelligence sources, we’re able to rapidly identify potential risks relevant to our infrastructure. Upon detection, vulnerabilities are triaged and addressed according to well-defined Service Level Agreements (SLAs) based on severity—ensuring that critical issues receive immediate attention and routine patches are managed efficiently. This structured, proactive posture helps us mitigate risk and maintain the ongoing security and stability of our environment. In the rare event that a critical vulnerability threatens operational security or integrity, we are prepared with fast rollback plans that allow us to swiftly revert to a secure state. These procedures are designed to be executed with minimal disruption, ensuring urgent patches can be applied without causing extended downtime for users or administrators. By integrating rapid response capabilities into our workflows, we’re able to act decisively and minimize exposure, all while maintaining service availability and reliability at the highest standard. Infrastructure security operations Secrets and data We enforce strict secret management practices by using a centralized vault or cloud-native secret store to handle all sensitive credentials, API keys, and configuration secrets. No secrets are ever embedded in source code or stored within deployment images, reducing the risk of accidental exposure. Secret rotation is scheduled regularly as part of our operational cadence, ensuring that credentials remain fresh and limiting the window of opportunity for misuse even if a secret were somehow compromised. All data is secured with encryption both at rest and in transit, leveraging strong cryptographic controls across storage and networking layers. Where supported, our databases rely on IAM-based authentication instead of static credentials, further minimizing the risk associated with traditional username-password pairs. This approach not only enhances security but also streamlines access control and auditability, underpinning our commitment to robust, modern data protection practices throughout the stack. Backups and disaster recovery Our disaster recovery strategy rests on maintaining versioned, immutable backups that cannot be altered or deleted, providing a reliable safeguard against data loss, corruption, or ransomware attacks. These backups are created on a regular schedule and include not only application data, but also content, media assets, and configuration files. We conduct periodic restore drills to validate that our backups are effective and to ensure our team is prepared to execute recovery procedures smoothly. Explicit Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) are defined, routinely tested, and adjusted as needed to meet the demands of our operations and regulatory obligations. Data recovery playbooks are meticulously maintained and encompass every critical aspect of our environment, from core content and media to infrastructure-as-code templates that can quickly and predictably rebuild our systems. These playbooks provide step-by-step guidance for recovering data and restoring services, whether in response to accidental deletion, hardware failure, or a targeted attack. By rigorously documenting and testing these processes, we ensure a high degree of resilience and confidence in our ability to restore normal operations with minimal disruption, safeguarding both our assets and the experience of our users. Observability and response We maintain a comprehensive observability stack with centralized, structured logging that aggregates data from all key layers—Nginx, PHP-FPM, WordPress, and supporting services. This logging is enriched with real-time metrics and distributed traces, giving us end-to-end visibility into application performance and user activity across our digital experience platform (DXP). All logs are funneled into a Security Information and Event Management (SIEM) system, which acts as the nerve center for detecting and investigating potential threats. Hosts and containers are further protected by Endpoint Detection and Response (EDR) solutions, providing continuous monitoring and the ability to quickly isolate and remediate suspicious behavior. To enhance detection and incident response, we employ automated anomaly detection and maintain detailed runbooks, dramatically reducing our mean time to detect (MTTD) and mean time to respond (MTTR) to issues. Our security posture is continually tested and validated through regular penetration tests and an active bug bounty program that focus on the entire surface of our DXP, not just on isolated components. This holistic approach ensures we proactively identify vulnerabilities, address weaknesses before they can be exploited, and ultimately maintain a resilient, trustworthy platform for our users and customers. Certifications Obtained When it comes to building or selecting hosting for your organization’s sensitive data and mission-critical applications, certifications matter—a lot. Obtaining FedRAMP Moderate certified ensures compliance with rigorous federal security standards, making it a necessity for government-related workloads and a great standard for any organization to abide. Similarly, a SOC 2 Type 1 certification demonstrates that a hosting provider has established robust systems and controls to protect data and ensure privacy, fostering client trust and accountability. GovRAMP Moderate is critical for U.S. government contractors working with state and local government workloads, ensuring additional layers of compliance and security. If your data processing touches on European clients or users, GDPR and the Data Privacy Framework offer reassurance that personal data is handled and processed lawfully, transparently, and securely. Equally important is the Microsoft SSPA, a must-have for vendors providing services to Microsoft or handling its data. Lastly, WCAG 2.0 AA compliance ensures that your hosted applications and websites are accessible to users and employees with disabilities, strengthening your commitment to inclusivity and expanding your reach. By prioritizing these certifications, organizations not only safeguard compliance and security, but also demonstrate a dedication to transparency, privacy, and accessibility in today’s digital landscape. Editorial workflow governance Workflow controls Every administrative and content-related event is thoroughly audit-logged, capturing a detailed trail of actions for review and oversight. These logs are fully exportable, supporting compliance with regulatory requirements and internal governance policies. By maintaining comprehensive and accessible audit records, we provide the transparency necessary to facilitate investigations, enforce accountability, and demonstrate adherence to best practices and legal obligations—ensuring peace of mind for our organization and stakeholders alike. Secure content operations We prioritize security awareness by providing editors with ongoing training on critical topics, such as phishing recognition, safe link practices, and our governance policies for embedded scripts and third-party widgets. This continual education helps staff identify and avoid social engineering attacks, understand the risks associated with external content, and adhere to protocols that maintain the integrity and security of our web platform. By empowering editors with the knowledge to make secure decisions, we reduce the likelihood of errors that could compromise the site or expose sensitive information. To further protect user interactions, especially on forms, we deploy layered anti-spam defenses, implement bot challenges like CAPTCHAs, and set server-side rate limits to prevent abuse. All form inputs are validated on the server, ensuring robust protection even if client-side checks are bypassed or disabled. This disciplined approach to input handling and abuse prevention ensures our forms remain a secure channel for legitimate user engagement while blocking malicious actors and automated attacks. Reliable and secure performance Caching strategy Our performance strategy centers on comprehensive caching and efficient data handling to deliver a fast, reliable experience for both users and administrators. Edge and page-level caching shield our origin servers by intercepting and serving frequent requests directly at the edge, dramatically reducing the number of dynamic requests that reach the core infrastructure. Object caching solutions like Redis, coupled with thoughtfully optimized queries, keep the admin interface responsive and ensure APIs remain quick even under load. We routinely profile database queries and set strict performance budgets for the slowest paths, preventing regressions that could degrade performance or escalate into broader availability issues. This layered approach ensures our platform stays speedy, stable, and scalable as demands grow. Build pipeline Every code change in our workflow is subjected to automated testing, with comprehensive suites that verify functionality, performance, and security. Security gates are tightly integrated into the CI/CD pipeline, ensuring that no changes are merged if any issues or vulnerabilities are detected. Our deployment processes are fully automated and repeatable, significantly reducing the potential for human error and guaranteeing that releases are consistent, predictable, and recoverable. By managing our infrastructure as code, we further ensure that all environments—from development to production—are consistent, auditable, and easily reproducible. This approach not only accelerates the provisioning of resources and the rollout of updates, but also strengthens compliance and traceability, providing a solid foundation for scalability, reliability, and continuous improvement. UX and SEO We finely tune our security headers and Content Security Policies (CSPs) to deliver robust protection without disrupting the user experience, ensuring that all site functionality remains seamless and accessible. Our commitment to performance extends to advanced image optimization, responsive asset delivery, and strict adherence to accessibility standards, enabling our content to load quickly and be usable by everyone. By consistently delivering fast, accessible pages, we not only enhance user engagement but also enable rapid, safe deployment cycles—minimizing potential attack windows through swift rollouts and efficient rollbacks, and maintaining both security and usability at the core of our platform. Alternatives considered Proprietary Digital Experience Platforms (DXPs) present a compelling all-in-one suite of features that can streamline operations for many organizations. However, their advantages often come with trade-offs: these platforms tend to be resource intensive, both in terms of infrastructure and licensing fees, and may lack the granular transparency required for deep security audits or targeted customizations. The inherent complexity and tightly-coupled nature of these solutions can slow the pace of change—making it challenging to adapt or patch emergent threats rapidly, which is itself a significant security and business risk in dynamic environments. Headless-only SaaS CMSes, on the other hand, are designed for flexibility and API excellence, offering developers modern tooling and a frictionless integration experience. Despite these strengths, organizations may encounter challenges such as vendor lock-in, which can limit strategic choices and agility over time. Control over patching and updates is usually in the hands of the SaaS provider, potentially creating gaps between issue discovery and remediation. Further, these platforms may present hurdles in regions with strict data residency or compliance requirements, making them less suitable for regulated industries or global enterprises with nuanced jurisdictional needs. Systems like Drupal or fully-custom CMS architectures can undoubtably satisfy enterprise requirements for scale, extensibility, and security. However, in our evaluation, team expertise, the maturity and momentum of the adjacent tooling ecosystem, and a clear view of total cost of ownership all ultimately favored the adoption of WordPress. WordPress’s balance of flexibility, a wealth of existing integrations, well-understood operational paradigms, and strong community support enables us to deliver on our goals efficiently while ensuring we maintain the adaptability, security, and cost-effectiveness our organization requires. WordPress provides the best mix of transparency, control, ecosystem breadth, and speed—when paired with our security architecture and operating model. Lessons learned and best practices Start headless and isolate the admin plane from day one. Enforce SSO and MFA, least privilege roles, and formal change approval. Treat plugins as third-party code: audit, monitor, and patch under SLAs. Invest in observability and rehearse incident response regularly. Keep WordPress core close to vanilla; extend through vetted plugins and mu-plugins, not core forks. Security is not a property of a tool; it’s the outcome of architecture, governance, and culture. With a decoupled design, rigorous controls, and a disciplined operational posture, WordPress is a strong foundation for the content layer of an enterprise DXP—combining the openness and speed teams want with the security and control the business requires of its MarTech stack.

Biotech platforms keep missing the mark on security fundamentals A new security posture report on the biotech sector shows how quickly attackers could reach sensitive health data with only basic reconnaissance. Researchers needed less than two hours per company to uncover exposed genomic records, unprotected APIs, and misconfigured systems, according to Sekurno. Real-world timeline showing how attackers could pivot from passive reconnaissance to accessing sensitive genomic data in under 2 hours. APIs exposing sensitive data APIs were the most common weakness, accounting for 34% of identified issues. In several cases, endpoints exposed personal information, such as patient IDs, genetic reports, and partner data, without requiring authentication. Some platforms also left developer documentation, including Swagger and GraphQL introspection, publicly accessible, successfully mapping the entire API surface. These conditions allowed unauthorized requests to succeed against endpoints that appeared secure. Internal system details leaking out More than half of the companies revealed internal details through verbose error messages, exposed configuration files, or non-minified JavaScript. These disclosures included usernames, user IDs, file paths, and backend framework information. In some cases, hardcoded secrets like API keys or private tokens were visible in frontend code. Verbose errors also revealed stack traces and server internals. Together, these leaks lowered the effort required to map systems and identify exploitable weaknesses. Corporate credentials easily found Around 36% of companies had corporate credentials discoverable through public sources. Many were email-password pairs linked to company domains, with some firms having 15 or more exposed combinations. These leaks originated from prior third-party breaches and stealer logs, pointing to widespread credential reuse. Even without testing their validity, the presence of these credentials demonstrated how easily attackers could attempt credential stuffing or account takeovers. Vulnerable, outdated software A number of companies were running outdated software with known vulnerabilities. This included unpatched versions of Apache HTTP Server and PHP, affected by multiple CVEs that could enable remote code execution or information disclosure. Some platforms also used vulnerable third-party libraries. The persistence of these outdated systems often pointed to gaps in asset inventory and the absence of structured vulnerability management, leaving internet-facing services exposed to automated scanning and exploitation. Publicly accessible development environments Several companies had staging or development environments exposed to the public. These often reused production logic or credentials and lacked proper access controls. Examples included open Kubernetes dashboards, default Apache pages, and publicly accessible databases. In some cases, the only safeguards were static credentials or basic form logins. These environments served as entry points that attackers could locate and exploit, sometimes with the same level of access as production systems. The risk landscape For companies handling genomic data and health records, these gaps represent both operational and reputational risk. The report warns that violations of HIPAA or GDPR are possibilities. Breaches could also shake investor confidence in a sector where trust is foundational to the adoption of personalized medicine. The report points to the 23andMe incident as a case in which overlooked controls, such as MFA or consent defaults, amplified the impact of a breach. Although the researchers did not attempt exploitation, the timeline presented shows how an attacker could move from passive reconnaissance to accessing live DNA reports in less than two hours. “We didn’t spend more than two hours per company, and yet weidentified expose d DNA data, multiple misconfigurations, weak (or even absent) authentication, exposed client databases, and more. We find this extremely concerning, as trust is fundamental to the evolution of this industry, and our findings show that this trust can be easily undermined”, said Demyd Maiornykov, CEO, Sekurno.

GitLab heeft kwetsbaarheden verholpen in GitLab CE/EE (Specifiek voor versies voor 18.2.7, 18.3.3, en 18.4.1). De kwetsbaarheden omvatten onder andere de mogelijkheid voor geauthenticeerde gebruikers om vertrouwelijke informatie te benaderen door projecten met dezelfde naam als die van het slachtoffer te creëren, en het verkrijgen van ongeautoriseerde toegang tot gevoelige informatie binnen virtuele registerconfiguraties. Daarnaast kunnen geauthenticeerde gebruikers een onbeschermde GraphQL API misbruiken, wat kan leiden tot een Denial-of-Service (DoS) situatie. Ook is er een privilege-escalatie kwetsbaarheid die het mogelijk maakt voor ontwikkelaars met specifieke rechten om ongeautoriseerde toegang te krijgen tot extra systeemcapaciteiten. Bovendien kunnen ongeauthenticeerde gebruikers een DoS-voorwaarde activeren door grote, speciaal gemaakte JSON-bestanden te uploaden. Tot slot is er een prestatieafname vastgesteld bij bepaalde versies van GitLab, wat de gebruikerservaring kan beïnvloeden.

Introduction The modern development world is almost entirely dependent on third-party modules. While this certainly speeds up development, it also creates a massive attack surface for end users, since anyone can create these components. It is no surprise that malicious modules are becoming more common. When a single maintainer account for popular modules or a single popular dependency is compromised, it can quickly turn into a supply chain attack. Such compromises are now a frequent attack vector trending among threat actors. In the last month alone, there have been two major incidents that confirm this interest in creating malicious modules, dependencies, and packages. We have already discussed the recent compromise of popular npm packages. September 16, 2025 saw reports of a new wave of npm package infections, caused by the self-propagating malware known as Shai-Hulud. Shai-Hulud is designed to steal sensitive data, expose private repositories of organizations, and hijack victim credentials to infect other packages and spread on. Over 500 packages were infected in this incident, including one with more than two million weekly downloads. As a result, developers who integrated these malicious packages into their projects risk losing sensitive data, and their own libraries could become infected with Shai-Hulud. This self-propagating malware takes over accounts and steals secrets to create new infected modules, spreading the threat along the dependency chain. Technical details The worm’s malicious code executes when an infected package is installed. It then publishes infected releases to all packages the victim has update permissions for. Once the infected package is installed from the npm registry on the victim’s system, a special command is automatically executed. This command launches a malicious script over 3 MB in size named bundle.js, which contains several legitimate, open-source work modules. Key modules within bundle.js include: Library for interacting with AWS cloud services GCP module that retrieves metadata from the Google Cloud Platform environment Functions for TruffleHog, a tool for scanning various data sources to find sensitive information, specifically secrets Tool for interacting with the GitHub API The JavaScript file also contains network utilities for data transfer and the main operational module, Shai-Hulud. The worm begins its malicious activity by collecting information about the victim’s operating system and checking for an npm token and authenticated GitHub user token in the environment. If a valid GitHub token is not present, bundle.js will terminate. A distinctive feature of Shai-Hulud is that most of its functionality is geared toward Linux and macOS systems: almost all malicious actions are performed exclusively on these systems, with the exception of using TruffleHog to find secrets. Exfiltrating secrets After passing the checks, the malware uses the token mentioned earlier to get information about the current GitHub user. It then runs the extraction function, which creates a temporary executable bash script at /tmp/processor.sh and runs it as a separate process, passing the token as an argument. Below is the extraction function, with strings and variable names modified for readability since the original source code was illegible. The bash script is designed to communicate with the GitHub API and collect secrets from the victim’s repository in an unconventional way. First, the script checks if the token has the necessary permissions to create branches and work with GitHub Actions. If it does, the script gets a list of all the repositories the user can access from 2025. In each of these, it creates a new branch named shai-hulud and uploads a shai-hulud-workflow.yml workflow, which is a configuration file for describing GitHub Actions workflows. These files are automation scripts that are triggered in GitHub Actions whenever changes are made to a repository. The Shai-Hulud workflow activates on every push. This file collects secrets from the victim’s repositories and forwards them to the attackers’ server. Before being sent, the confidential data is encoded twice with Base64. This unusual method for data collection is designed for a one-time extraction of secrets from a user’s repositories. However, it poses a threat not only to Shai-Hulud victims but also to ordinary researchers. If you search for “shai-hulud” on GitHub, you will find numerous repositories that have been compromised by the worm. The main bundle.js script then requests a list of all organizations associated with the victim and runs the migration function for each one. This function also runs a bash script, but in this case, it saves it to /tmp/migrate-repos.sh, passing the organization name, username, and token as parameters for further malicious activity. The bash script automates the migration of all private and internal repositories from the specified GitHub organization to the user’s account, making them public. The script also uses the GitHub API to copy the contents of the private repositories as mirrors. We believe these actions are intended for the automated theft of source code from the private repositories of popular communities and organizations. For example, the well-known company CrowdStrike was caught in this wave of infections. The worm’s self-replication After running operations on the victim’s GitHub, the main bundle.js script moves on to its next crucial stage: self-replication. First, the script gets a list of the victim’s 20 most downloaded packages. To do this, it performs a search query with the username from the previously obtained npm token: Next, for each of the packages it finds, it calls the updatePackage function. This function first attempts to download the tarball version of the package (a .TAR archive). If it exists, a temporary directory named npm-update-{target_package_name} is created. The tarball version of the package is saved there as package.tgz, then unpacked and modified as follows: The malicious bundle.js is added to the original package. A postinstall command is added to the package.json file (which is used in Node.js projects to manage dependencies and project metadata). This command is configured to execute the malicious script vianode bundle.js . The package version number is incremented by 1. The modified package is then re-packed and published to npm as a new version with the npm publish command. After this, the temporary directory for the package is cleared. Uploading secrets to GitHub Next, the worm uses the previously mentioned TruffleHog utility to harvest secrets from the target system. It downloads the latest version of the utility from the original repository for the specific operating system type using the following link: The worm also uses modules for AWS and Google Cloud Platform (GCP) to scan for secrets. The script then aggregates the collected data into a single object and creates a repository named “Shai-Hulud” in the victim’s profile. It then uploads the collected information to this repository as a data.json file. Below is a list of data formats collected from the victim’s system and uploaded to GitHub: Infection characteristics A distinctive characteristic of the modified packages is that they contain an archive named package.tar. This is worth noting because packages usually contain an archive with a name that matches the package itself. Through our research, we were able to identify the first package from which Shai-Hulud began to spread, thanks to a key difference. As we mentioned earlier, after infection, a postinstall command to execute the malicious script, node bundle.js, is written to the package.json file. This command typically runs immediately after installation. However, we discovered that one of the infected packages listed the same command as a preinstall command, meaning it ran before the installation. This package was ngx-bootstrap version 18.1.4. We believe this was the starting point for the spread of this infection. This hypothesis is further supported by the fact that the archive name in the first infected version of this package differed from the name characteristic of later infected packages (package.tar). While investigating different packages, we noticed that in some cases, a single package contained multiple versions with malicious code. This was likely possible because the infection spread to all maintainers and contributors of packages, and the malicious code was then introduced from each of their accounts. Infected libraries and CrowdStrike The rapidly spreading Shai-Hulud worm has infected many popular libraries that organizations and developers use daily. Shai-Hulud has infected over 500 popular packages in recent days, including libraries from the well-known company CrowdStrike. Among the infected libraries were the following: @crowdstrike/commitlint versions 8.1.1, 8.1.2 @crowdstrike/falcon-shoelace versions 0.4.1, 0.4.2 @crowdstrike/foundry-js versions 0.19.1, 0.19.2 @crowdstrike/glide-core versions 0.34.2, 0.34.3 @crowdstrike/logscale-dashboard versions 1.205.1, 1.205.2 @crowdstrike/logscale-file-editor versions 1.205.1, 1.205.2 @crowdstrike/logscale-parser-edit versions 1.205.1, 1.205.2 @crowdstrike/logscale-search versions 1.205.1, 1.205.2 @crowdstrike/tailwind-toucan-base versions 5.0.1, 5.0.2 But the event that has drawn significant attention to this spreading threat was the infection of the @ctrl/tinycolor library, which is downloaded by over two million users every week. As mentioned above, the malicious script exposes an organization’s private repositories, posing a serious threat to their owners, as this creates a risk of exposing the source code of their libraries and products, among other things, and leading to an even greater loss of data. Prevention and protection To protect against this type of infection, we recommend using a specialized solution for monitoring open-source components. Kaspersky maintains a continuous feed of compromised packages and libraries, which can be used to secure your supply chain and protect development from similar threats. For personal devices, we recommend Kaspersky Premium, which provides multi-layered protection to prevent and neutralize infection threats. Our solution can also restore the device’s functionality if it’s infected with malware. For corporate devices, we advise implementing a comprehensive solution like Kaspersky Next, which allows you to build a flexible and effective security system. This product line provides threat visibility and real-time protection, as well as EDR and XDR capabilities for investigation and response. It is suitable for organizations of any scale or industry. Kaspersky products detect the Shai-Hulud threat as HEUR:Worm.Script.Shulud.gen. In the event of a Shai-Hulud infection, and as a proactive response to the spreading threat, we recommend taking the following measures across your systems and infrastructure: Use a reliable security solution to conduct a full system scan. Audit your GitHub repositories: Check for repositories named shai-hulud . Look for non-trivial or unknown branches, pull requests, and files. Audit GitHub Actions logs for strings containing shai-hulud . Reissue npm and GitHub tokens, cloud keys (specifically for AWS and Google Cloud Platform), and rotate other secrets. Clear the cache and inventory your npm modules: check for malicious ones and roll back versions to clean ones. Check for indicators of compromise, such as files in the system or network artifacts. Indicators of compromise Files: bundle.js shai-hulud-workflow.yml Strings: shai-hulud Hashes: C96FBBE010DD4C5BFB801780856EC228 78E701F42B76CCDE3F2678E548886860 Network artifacts: https://webhook.site/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7 Compromised packages: @ahmedhfarag/ngx-perfect-scrollbar @ahmedhfarag/ngx-virtual-scroller @art-ws/common @art-ws/config-eslint @art-ws/config-ts @art-ws/db-context @art-ws/di @art-ws/di-node @art-ws/eslint @art-ws/fastify-http-server @art-ws/http-server @art-ws/openapi @art-ws/package-base @art-ws/prettier @art-ws/slf @art-ws/ssl-info @art-ws/web-app @basic-ui-components-stc/basic-ui-components @crowdstrike/commitlint @crowdstrike/falcon-shoelace @crowdstrike/foundry-js @crowdstrike/glide-core @crowdstrike/logscale-dashboard @crowdstrike/logscale-file-editor @crowdstrike/logscale-parser-edit @crowdstrike/logscale-search @crowdstrike/tailwind-toucan-base @ctrl/deluge @ctrl/golang-template @ctrl/magnet-link @ctrl/ngx-codemirror @ctrl/ngx-csv @ctrl/ngx-emoji-mart @ctrl/ngx-rightclick @ctrl/qbittorrent @ctrl/react-adsense @ctrl/shared-torrent @ctrl/tinycolor @ctrl/torrent-file @ctrl/transmission @ctrl/ts-base32 @nativescript-community/arraybuffers @nativescript-community/gesturehandler @nativescript-community/perms @nativescript-community/sentry @nativescript-community/sqlite @nativescript-community/text @nativescript-community/typeorm @nativescript-community/ui-collectionview @nativescript-community/ui-document-picker @nativescript-community/ui-drawer @nativescript-community/ui-image @nativescript-community/ui-label @nativescript-community/ui-material-bottom-navigation @nativescript-community/ui-material-bottomsheet @nativescript-community/ui-material-core @nativescript-community/ui-material-core-tabs @nativescript-community/ui-material-ripple @nativescript-community/ui-material-tabs @nativescript-community/ui-pager @nativescript-community/ui-pulltorefresh @nstudio/angular @nstudio/focus @nstudio/nativescript-checkbox @nstudio/nativescript-loading-indicator @nstudio/ui-collectionview @nstudio/web @nstudio/web-angular @nstudio/xplat @nstudio/xplat-utils @operato/board @operato/data-grist @operato/graphql @operato/headroom @operato/help @operato/i18n @operato/input @operato/layout @operato/popup @operato/pull-to-refresh @operato/shell @operato/styles @operato/utils @teselagen/bio-parsers @teselagen/bounce-loader @teselagen/file-utils @teselagen/liquibase-tools @teselagen/ove @teselagen/range-utils @teselagen/react-list @teselagen/react-table @teselagen/sequence-utils @teselagen/ui @thangved/callback-window @things-factory/attachment-base @things-factory/auth-base @things-factory/email-base @things-factory/env @things-factory/integration-base @things-factory/integration-marketplace @things-factory/shell @tnf-dev/api @tnf-dev/core @tnf-dev/js @tnf-dev/mui @tnf-dev/react @ui-ux-gang/devextreme-angular-rpk @ui-ux-gang/devextreme-rpk @yoobic/design-system @yoobic/jpeg-camera-es6 @yoobic/yobi ace-colorpicker-rpk airchief airpilot angulartics2 another-shai browser-webdriver-downloader capacitor-notificationhandler capacitor-plugin-healthapp capacitor-plugin-ihealth capacitor-plugin-vonage capacitorandroidpermissions config-cordova cordova-plugin-voxeet2 cordova-voxeet create-hest-app db-evo devextreme-angular-rpk devextreme-rpk ember-browser-services ember-headless-form ember-headless-form-yup ember-headless-table ember-url-hash-polyfill ember-velcro encounter-playground eslint-config-crowdstrike eslint-config-crowdstrike-node eslint-config-teselagen globalize-rpk graphql-sequelize-teselagen json-rules-engine-simplified jumpgate koa2-swagger-ui mcfly-semantic-release mcp-knowledge-base mcp-knowledge-graph mobioffice-cli monorepo-next mstate-angular mstate-cli mstate-dev-react mstate-react ng-imports-checker ng2-file-upload ngx-bootstrap ngx-color ngx-toastr ngx-trend ngx-ws oradm-to-gql oradm-to-sqlz ove-auto-annotate pm2-gelf-json printjs-rpk react-complaint-image react-jsonschema-form-conditionals react-jsonschema-form-extras react-jsonschema-rxnt-extras remark-preset-lint-crowdstrike rxnt-authentication rxnt-healthchecks-nestjs rxnt-kue swc-plugin-component-annotate tbssnch teselagen-interval-tree tg-client-query-builder tg-redbird tg-seq-gen thangved-react-grid ts-gaussian ts-imports tvi-cli ve-bamreader ve-editor verror-extra voip-callkit wdio-web-reporter yargs-help-output yoo-styles

Multiple CVEs in the Chaos-Mesh platform have been discovered, including three critical vulnerabilities that allow in-cluster attackers to run arbitrary code on any pod, even in the default configuration. According to new research by JFrog Security Research, the flaws are tracked as CVE-2025-59358, CVE-2025-59360, CVE-2025-59361 and CVE-2025-59359. They affect the Chaos Controller Manager and expose a GraphQL debug server that accepts unauthenticated queries. JFrog's analysis, published on Tuesday, shows the controller exposes a ClusterIP GraphQL endpoint on port 10082 that, by default, does not enforce authentication for the /query path. Attackers with network access inside a cluster can call GraphQL mutations to trigger native fault injections, such as killing processes and modifying iptables. “Platforms such as Chaos-Mesh give, by design, complete control of the Kubernetes cluster to the platform,” said Shachar Menashe, VP of security research at JFrog. “This flexibility can become a critical risk when vulnerabilities such as Chaotic Deputy are discovered.” The three critical CVEs (CVE-2025-59360, CVE-2025-59361 and CVE-2025-59359) each have a CVSS score of 9.8 and allow straightforward OS command injection because user input is concatenated directly into shell commands executed via the platform’s ExecBypass routine. How Attackers Can Exploit Chaotic Deputy The Controller Manager can instruct the Chaos Daemon to run commands on other pods. Using exposed namespaces under /proc//root and the nsexec helper, an attacker can copy service account tokens from target pods into their own pod, thereby escalating privileges cluster-wide. Demonstrations include executing a killProcesses mutation against kube-apiserver and copying tokens via a crafted cleanTcs request. Managed offerings that integrate Chaos-Mesh, such as Azure Chaos Studio, may also be affected. Key affected elements include: Exposed GraphQL /query endpoint on port 10082 Command-building in cleanTcs, killProcesses, cleanIptables resolvers Ability to access other pods’ files via /proc based nsexec Patches, Workarounds and Security Response Users are urged to upgrade to Chaos-Mesh 2.7.3 immediately. “We recommend that Chaos-Mesh users upgrade swiftly since these vulnerabilities are extremely easy to exploit and lead to total cluster takeover,” Menashe added. “We also want to offer our thanks to the Chaos-Mesh maintainers for their rapid response and collaboration in addressing these critical security issues.” As a temporary workaround, redeploying the Helm chart with the control server disabled will reduce exposure. The report concludes that while external exploitation requires cluster network access, in-cluster compromises are common enough to make these vulnerabilities highly dangerous and easy to exploit.

Chaotic Deputy: vulnerabilità critiche nella piattaforma di chaos engineering per Kubernetes Alert AL01/250917/CSIRT-ITA Sintesi Aggiornamenti di sicurezza sanano quattro vulnerabilità, di cui 3 con gravità “critica”, in Chaos Mesh, piattaforma di chaos engineering per Kubernetes. Tali vulnerabilità, che interessano il server GraphQL di debug, potrebbero consentire a un utente malintenzionato l’esecuzione di comandi arbitrari e il conseguente controllo dell’intero cluster. Tipologia Arbitrary Code Execution Denial of Service Descrizione e potenziali impatti Chaos Mesh è una piattaforma open source per il “chaos engineering” su Kubernetes: tale prodotto permette di simulare guasti (fault injection) su pod, network, filesystem, kernel, ecc., al fine di testare la resilienza e comportamento del sistema. Ricercatori di sicurezza hanno recentemente scoperto 4 vulnerabilità - denominate “Chaotic Deputy” e presenti nella configurazione di default del prodotto - di cui 3 identificate tramite le CVE-2025-59359, CVE-2025-59360, CVE-2025-59361 con score CVSS v3.x pari a 9.8. Tali vulnerabilità potrebbero consentire l’iniezione di comandi al sistema operativo sottostante tramite mutazioni[1] (mutations) come cleanTcs, killProcesses, cleanIptables. Un potenziale attaccante con accesso al cluster, anche tramite un pod non privilegiato, risulterebbe in grado di eseguire comandi arbitrari su altri pod, rubare token di service account, effettuare movimenti laterali e, potenzialmente, prendere controllo del cluster La quarta vulnerabilità, identificata tramite la CVE-2025-59358 e con score CVSS v3.x pari a 7.5, potrebbe permettere la compromissione della disponibilità del servizio, tramite un server GraphQL di debug esposto su Internet privo di meccanismi di autenticazione. Prodotti e versioni affette Chaos Mesh, versioni precedenti alla 2.7.3 Azioni di mitigazione Ove non provveduto, si raccomanda di aggiornare tempestivamente i prodotti vulnerabili all’ultima versione disponibile. Ove l’aggiornamento tempestivo non fosse possibile, è necessario ridistribuire il chart Helm impostando enableCtrlServer=false per disabilitare lo strumento chaosctl e chiudere la porta di controllo del server GraphQL (chaos-controller-manager) 10082. helm install chaos-mesh chaos-mesh/chaos-mesh -n=chaos-mesh --version 2.7.x --set enableCtrlServer=false [1] Le mutation in Chaos Mesh sono le chiamate GraphQL utilizzate per comandare esperimenti e pulire l’ambiente. Sono pensate per sviluppatori, ma se l’endpoint resta esposto e non aggiornato diventano un punto d’ingresso per eseguire comandi malevoli nel cluster.

Cybersecurity researchers have disclosed multiple critical security vulnerabilities in Chaos Mesh that, if successfully exploited, could lead to cluster takeover in Kubernetes environments. "Attackers need only minimal in-cluster network access to exploit these vulnerabilities, execute the platform's fault injections (such as shutting down pods or disrupting network communications), and perform further malicious actions, including stealing privileged service account tokens," JFrog said in a report shared with The Hacker News. Chaos Mesh is an open-source cloud-native Chaos Engineering platform that offers various types of fault simulation and simulates various abnormalities that might occur during the software development lifecycle. The issues, collectively called Chaotic Deputy, are listed below - CVE-2025-59358 (CVSS score: 7.5) - The Chaos Controller Manager in Chaos Mesh exposes a GraphQL debugging server without authentication to the entire Kubernetes cluster, which provides an API to kill arbitrary processes in any Kubernetes pod, leading to cluster-wide denial-of-service CVE-2025-59359 (CVSS score: 9.8) - The cleanTcs mutation in Chaos Controller Manager is vulnerable to operating system command injection CVE-2025-59360 (CVSS score: 9.8) - The killProcesses mutation in Chaos Controller Manager is vulnerable to operating system command injection CVE-2025-59361 (CVSS score: 9.8) - The cleanIptables mutation in Chaos Controller Manager is vulnerable to operating system command injection An in-cluster attacker, i.e., a threat actor with initial access to the cluster's network, could chain CVE-2025-59359, CVE-2025-59360, CVE-2025-59361, or with CVE-2025-59358 to perform remote code execution across the cluster, even in the default configuration of Chaos Mesh. JFrog said the vulnerabilities stem from insufficient authentication mechanisms within the Chaos Controller Manager’s GraphQL server, allowing unauthenticated attackers to run arbitrary commands on the Chaos Daemon, resulting in cluster takeover. Threat actors could then leverage the access to potentially exfiltrate sensitive data, disrupt critical services, or even move laterally across the cluster to escalate privileges. Following responsible disclosure on May 6, 2025, all the identified shortcomings were addressed by Chaos Mesh with the release of version 2.7.3 on August 21. Users are advised to update their installations to the latest version as soon as possible. If immediate patching is not an option, it's recommended to restrict network traffic to the Chaos Mesh daemon and API server, and avoid running Chaos Mesh in open or loosely secured environments. "Platforms such as Chaos Mesh give, by design, complete control of the Kubernetes cluster to the platform," Shachar Menashe, vice president of security research at JFrog, said in a statement shared with The Hacker News. "This flexibility can become a critical risk when vulnerabilities such as Chaotic Deputy are discovered."