Mar 31, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Scenari, Tecnologia, Tecnologia 0

---

Il concetto di vibecoding – ovvero la generazione di codice direttamente da prompt in linguaggio naturale tramite modelli di intelligenza artificiale – sta rapidamente trasformando il modo in cui il software viene progettato e rilasciato. Un blogpost sul sito di Trend Micro analizza come questa nuova modalità di sviluppo ed elenca alcuni possibili scenari in cui l’uso di questa tecnologia, pur abilitando velocità senza precedenti, potrebbe introdurre una superficie di rischio radicalmente diversa, che impatta direttamente sui modelli di sicurezza applicativa e governance del codice.

Se da un lato l’AI consente di passare dall’idea al prodotto in tempi estremamente ridotti, dall’altro l’aumento esponenziale della velocità e del volume delle modifiche software potrebbe superare la capacità dei controlli di sicurezza se non pensati appositamente per questa nuova situazione, mettendo sotto stress processi di revisione, validazione e responsabilità.

Velocità senza comprensione: il nuovo paradigma del rischio

Nel modello di sviluppo tradizionale, il codice attraversa diversi livelli di controllo: scrittura, revisione tra pari, testing e validazione. Il vibecoding comprime drasticamente queste fasi, portando gli sviluppatori a concentrarsi principalmente sulla funzionalità.

Il punto critico è che il codice generato viene spesso accettato perché “funziona”, non perché è stato compreso o validato dal punto di vista della sicurezza. Questo introduce una rottura strutturale: chi rilascia il software potrebbe non essere in grado di spiegare nel dettaglio cosa fa realmente il codice. Il risultato è un cambio di priorità implicito, dove la sicurezza diventa un’attività differita anziché integrata nel ciclo di sviluppo.

Codice generato, rischio implicito: cosa introduce davvero un prompt

Un prompt non produce mai solo logica applicativa. Ogni generazione porta con sé scelte architetturali, librerie, configurazioni e pattern che spesso non vengono analizzati.

Il rischio reale è che ogni singola interazione con l’AI introduca componenti invisibili al processo decisionale dello sviluppatore, ampliando la superficie d’attacco in modo non intenzionale.

Tra gli effetti più rilevanti emergono dipendenze non esplicitamente selezionate, configurazioni permissive pensate per ambienti di test, gestione debole dei segreti e logiche applicative limitate ai casi standard. In questo contesto, la sicurezza non viene violata da un singolo errore critico, ma da una serie di decisioni apparentemente innocue che si accumulano nel tempo.

Debito di sicurezza: una deriva sistemica e silenziosa

Il vibecoding accelera la formazione del cosiddetto security debt, ovvero l’accumulo di vulnerabilità latenti generate da compromessi rapidi e non analizzati.

Il debito di sicurezza non nasce da errori evidenti, ma dalla somma di modifiche rapide che non vengono sottoposte a threat modeling o revisione approfondita. Ogni nuova funzione, endpoint o integrazione aggiunta “velocemente” contribuisce a costruire una base di codice sempre più difficile da governare.

Questo fenomeno è particolarmente critico nei contesti enterprise, dove il codice entra rapidamente in produzione e diventa parte di sistemi complessi e interconnessi.

Il problema dell’ownership: responsabilità frammentata

Uno degli effetti meno evidenti ma più critici del vibecoding riguarda la perdita di ownership chiara sul codice. La responsabilità si distribuisce tra chi scrive il prompt, il modello AI che genera il codice, chi lo approva e chi lo gestisce in produzione, creando una catena decisionale opaca.

Anche quando esiste un “committer”, mancano spesso informazioni fondamentali come il contesto di generazione, le motivazioni tecniche e le dipendenze introdotte. Questo rende estremamente complesso intervenire su problemi di sicurezza: la mancanza di contesto trasforma ogni correzione in un’attività di reverse engineering, aumentando tempi e costi di remediation.

Revisione e controlli: quando l’AI valida sé stessa

Un ulteriore elemento di rischio emerge quando lo stesso sistema di AI viene utilizzato sia per generare codice sia per validarlo. Si crea così un’illusione di revisione, senza una reale separazione dei ruoli e delle responsabilità, compromettendo uno dei principi fondamentali della sicurezza: l’indipendenza dei controlli.

In questo scenario, i controlli tradizionali non vengono eliminati, ma semplicemente sovraccaricati da un volume di cambiamenti che non sono stati progettati per gestire.

Il vero rischio: software change fuori controllo

Il punto centrale non è la qualità del codice generato dall’AI, ma la perdita di controllo sul processo di sviluppo. Il rischio più rilevante del vibecoding è l’introduzione di cambiamenti software continui, veloci e non completamente governati, che superano la capacità delle organizzazioni di monitorare cosa viene realmente distribuito in produzione.

L’AI amplifica dinamiche già esistenti – riuso di librerie, configurazioni errate, sviluppo sotto pressione – portandole a una scala e a una velocità senza precedenti.

Sicurezza adattiva: come devono evolvere i controlli

Se il vibecoding è destinato a diventare la norma, la sicurezza deve cambiare approccio. La protezione efficace non può più basarsi su controlli a valle, ma deve intervenire nelle fasi iniziali del ciclo di sviluppo, intercettando i rischi nel momento in cui vengono introdotti.

Diventa fondamentale automatizzare le policy di sicurezza, integrare i controlli nei workflow CI/CD e creare un contesto condiviso tra team di sviluppo e sicurezza. Solo in questo modo è possibile mantenere la velocità senza sacrificare la governance.

Il ruolo delle piattaforme integrate

L’aumento della complessità rende sempre meno efficaci gli strumenti isolati. Le piattaforme integrate di code security emergono come elemento chiave per scalare i controlli insieme alla velocità di sviluppo, permettendo di correlare codice, dipendenze, policy e pipeline di rilascio.

La differenza non è tanto nelle funzionalità, quanto nel momento in cui la sicurezza interviene: quando è anticipata, diventa supporto allo sviluppo; quando è tardiva, viene percepita come ostacolo.

Il vibecoding non è un fenomeno temporaneo, ma una trasformazione strutturale dello sviluppo software. Il vero problema non è l’AI che scrive codice insicuro, ma il fatto che gli sviluppatori possano rilasciare codice che non hanno avuto il tempo di comprendere e proteggere. Secondo Trend Micro, le organizzazioni che avranno successo non saranno quelle che limiteranno l’uso dell’AI, ma quelle che sapranno integrare sicurezza, governance e sviluppo in un modello coerente con questa nuova realtà.

---

---

---

https://www.securityinfo.it/2026/03/31/vibecoding-lai-accelera-lo-sviluppo-ma-moltiplica-i-rischi/?utm_source=rss&utm_medium=rss&utm_campaign=vibecoding-lai-accelera-lo-sviluppo-ma-moltiplica-i-rischi

WordPress 7.0, previously scheduled for an April 9th release, will be delayed in order to stabilize the Real-Time Collaboration feature and assure that the release, a major milestone, will “target extreme stability.” Much is riding on WordPress 7.0 as it will ship with features that will usher in the age of AI-driven content management systems.

Prioritization Of Stability

Matt Mullenweg, co-founder of WordPress, commenting in the official Making WordPress Slack workspace, said the release should step back from its current trajectory and prioritize stability, calling for a longer pre-release phase to get the real-time collaboration (RTC) feature working correctly. The delay is expected to last weeks, not days, and is described as a one-off deviation from WordPress’s planned date-driven schedule.

Mullenweg posted:

“Given the scope and status of 7.0, I think we should go back to beta releases, get the new tables right, lock in everything we want for 7.0, and then start RCs again. Date-driven is still our default, but for this milestone release we want to target extreme stability and exciting updates, especially as AI-accelerated development is increasing people’s expectations for software.

This is a one-off, I think for future we should get back on the scheduled train, with an aim for 4-a-year in 2027, to hopefully reflect our AI-enabled ability to move faster.”

Extended Release Candidate Phase Replaces Beta Reversion

To avoid technical compatibility issues, the project will remain in the release candidate phase, extending the testing period through additional RC builds as needed.

The proposal to return to beta releases was rejected because it would break PHP version comparison behavior, plugin update logic, and tooling that depends on standard version sequencing. Continuing with RC builds preserves compatibility while allowing more time for testing and fixes.

Real-Time Collaboration

The delay is largely due to the Real-Time Collaboration feature, which introduces new database tables and changes how WordPress handles editing sessions. Contributors identified risks related to performance, data handling, and interactions with existing systems.

A primary concern is that real-time editing currently disables persistent post caches during active sessions, a performance issue the team is working to resolve before the final release.

Database Design Raises Performance Concerns

A key part of the discussion focused on how to structure the database for Real-Time Collaboration (RTC).  A proposed single RTC table would support 1. real-time editing updates and 2. synchronization. But some contributors noted that the workloads for real-time editing and synchronization are fundamentally different.

Real-time collaboration generates high-frequency, bursty writes that require low latency (meaning updates happen with very little delay).

While synchronization between environments involves slower, structured updates that may include full-table scans.

Combining both patterns within one table risks performance issues and added complexity. Contributors discussed separating these workloads into separate tables optimized for each use case, but no decision has been made.

Gap In Release Candidate Testing Raises Concern

The discussion in the WordPress Slack workspace also raised concern over whether there was enough real-world release candidate testing, and database schema changes increase the risk of failures during upgrades. The solution of using the Gutenberg plugin for testing was rejected because database changes could affect production sites and require complex migration logic. Instead, the project will use an extended RC phase to increase testing exposure and gather feedback from a wider group of users.

Versioning Constraints

The proposal to delay version 7.0 led to additional issues. PHP version comparison rules and related tooling complicated returning to beta versions. It was agreed that staying within the release candidate sequence (ergo RC1, RC2, RC3) avoids these issues while allowing continued iteration, so it was decided to continue with release candidates.

Future Release Cadence Remains

The delay is described as a temporary exception. Matt Mullenweg said the project intends to return to a regular release schedule, with a goal of delivering roughly four releases per year by 2027 as development speeds increase with AI-assisted workflows.

Implications For Developers And Users

Developers should expect continued changes to the Real-Time Collaboration feature and its supporting database structures during the extended release candidate phase. The longer testing period provides more time to identify issues before release. For site owners and hosts, the delay shows that WordPress is prioritizing stability over schedule while introducing more complex real-time and synchronization features.

Impact Of RTC On Hosting Environments

Something that wasn’t discussed but is a real issue is how real-time collaboration might affect web hosting providers. They need to test that feature to see if it introduces issues on shared hosting environments. While RTC will be shipping with the feature turned off by default, the impact of it being used by customers in a shared hosting environment is currently unknown. A spokesperson for managed WordPress hosting provider Kinsta told Search Engine Journal they are still testing. Given how the feature is still evolving, Kinsta and other web hosts will have to continue testing the upcoming WordPress release candidates.

I think most people will agree that the decision to delay the release of WordPress 7.0 is the right call.

https://www.searchenginejournal.com/wordpress-delays-release-of-version-7-0-to-focus-on-stability/570944/

Google’s Gary Illyes and Martin Splitt used a recent episode of the Search Off the Record podcast to discuss whether webpages are getting too large and what that means for both users and crawlers.

The conversation started with a simple question: are websites getting fat? Splitt immediately pushed back on the framing, arguing that website-level size is meaningless. Individual page size is where the discussion belongs.

What The Data Shows

Splitt cited the 2025 Web Almanac from HTTP Archive, which found that the median mobile homepage weighed 845 KB in 2015. By July, that same median page had grown to 2,362 KB. That’s roughly a 3x increase over a decade.

Both agreed the growth was expected, given the complexity of modern web applications. But the numbers still surprised them.

Splitt noted the challenge of even defining “page weight” consistently, since different people interpret the term differently depending on whether they’re thinking about raw HTML, transferred bytes, or everything a browser needs to render a page.

How Google’s Crawl Limits Fit In

Illyes discussed a 15 MB default that applies across Google’s broader crawl infrastructure, where each URL gets its own limit, and referenced resources like CSS, JavaScript, and images are fetched separately.

That’s a different number from what appears in Google’s current Googlebot documentation. Google states that Googlebot for Google Search crawls the first 2 MB of a supported file type and the first 64 MB of a PDF.

Our previous coverage broke down the documentation update that clarified these figures earlier this year. Illyes and Splitt discussed the flexibility of these limits in a previous episode, noting that internal teams can override the defaults depending on what’s being crawled.

The Structured Data Question

One of the more interesting moments came when Illyes raised the topic of structured data and page bloat. He traced it back to a statement from Google co-founder Sergey Brin, who said early in Google’s history that machines should be able to figure out everything they need from text alone.

Illyes noted that structured data exists for machines, not users, and that adding the full range of Google’s supported structured data types to a page can add weight that visitors never see. He framed it as a tension rather than offering a clear answer on whether it’s a problem.

Does It Still Matter?

Splitt said yes. He acknowledged that his home internet connection is fast enough that page weight is irrelevant in his daily experience. But he said the picture changes when traveling to areas with slower connections, and noted that metered satellite internet made him rethink how much data websites transfer.

He suggested that page size growth may have outpaced improvements in median mobile connection speeds, though he said he’d need to verify that against actual data.

Illyes referenced prior studies suggesting that faster websites tend to have better retention and conversion rates, though the episode didn’t cite specific research.

Looking Ahead

Splitt said he plans to address specific techniques for reducing page size in a future episode.

Most pages are still unlikely to hit those limits, with the Web Almanac reporting a median mobile homepage size of 2,362 KB. But the broader trend of growing page weight affects both performance and accessibility for users on slower or metered connections.

https://www.searchenginejournal.com/google-pages-are-getting-larger-it-still-matters/570875/

Jobs with the highest potential for AI-assisted productivity gains also face the highest projected job losses, according to a new index from Digital Planet at Tufts University’s Fletcher School.

The American AI Jobs Risk Index ranks 784 U.S. occupations, 530 metro areas, 50 states, and 20 industry sectors by vulnerability to AI-driven job loss.

All figures are model projections based on AI adoption scenarios, not actual layoffs or employment changes. The median scenario estimates 9.3 million jobs at risk, ranging from 2.7 million to 19.5 million depending on AI adoption speed.

Which Jobs Face The Highest Projected Risk

Writers and authors top the list of occupations at risk at 57%. Computer programmers and web and digital interface designers follow at 55% each. Editors are at 54%, and web developers at 46%.

Market research analysts and marketing specialists face a projected 35% job loss rate. Public relations specialists are at 37%. News analysts, reporters, and journalists face 35% risk.

Earlier analyses, such as the Anthropic Economic Index and Stanford’s “Canaries in the Coal Mine,” measured how accessible jobs are to AI. This analysis goes further by estimating how likely that exposure is to translate into projected job loss.

Augmentation & Loss Risk Go Together

Authors refer to the connection between jobs that benefit from AI-driven productivity gains and those expected to lose jobs as the “augmentation-displacement link.”

When AI increases individual workers’ efficiency, companies can produce the same output with fewer employees. This mainly affects entry-level and lower-seniority roles first, because companies can cut back on hiring rather than firing.

Writing, programming, web design, technical writing, and data analysis are where this pattern is most evident. Tasks in these fields are cognitive, language-intensive, and structured enough for large language models to manage.

By Industry

Average vulnerability across all industries is about 6%. Sectors with the highest projected job loss are Information (18%), Finance and Insurance (16%), and Professional, Scientific, and Technical Services (16%).

Software Developers, Management Analysts, and Market Research Analysts face the biggest total income losses. These three roles combine high pay with large workforces, accounting for a significant share of the projected $757 billion in total at-risk annual income.

What The Analysis Doesn’t Include

Note that job creation effects aren’t included in this version. The authors intend to add that data in future updates as they gather more evidence.

Additionally, regulatory constraints, union bargaining power, and occupational licensing requirements that could help slow job losses in some sectors are not part of this analysis. The authors emphasize that their forecasts are based on different scenarios rather than being definitive.

Why This Matters

There’s a common assumption among digital professionals that using AI to boost productivity protects their jobs. However, this data challenges that idea.

SEJ previously covered this tension in 2023 when Dr. Craig Froehle of the University of Cincinnati warned that companies not investing in employee retraining would see turnover costs double. The Tufts data puts numbers on the specific occupations where that pressure is building.

Looking Ahead

Updates to the American AI Jobs Risk Index will be made as AI capabilities and labor market conditions evolve. The authors mention that future versions will try to include job creation data along with loss estimates, providing a more complete view of AI’s overall impact on employment.

The methodology is available on the Digital Planet site, which also links to a data download page.

---

Featured Image: rudall30/Shutterstock

https://www.searchenginejournal.com/new-ai-jobs-index-ranks-784-occupations-by-loss-risk/570867/

Mar 27, 2026 Giancarlo Calzetta In evidenza, News, RSS, Tecnologia 0

---

Google ha annunciato sul proprio blog l’obiettivo di completare l’integrazione della post-quantum cryptography (PQC) nei propri sistemi, prodotti e servizi entro il 2029, segnando uno dei piani più strutturati e ambiziosi finora dichiarati nel settore.

Per quanto l’avvento di computer quantistici in grado di spezzare le crittografie attuali sembri ancora molto in là dal giungere alla portata di governi e aziende, il tema è già molto sentito a causa della pratica, finora speculativa ma destinata a diventare attuale, del “raccogli adesso e decripta più tardi”: ovvero il fatto che gli attaccanti potrebbero rubare adesso gli archivi criptati e tenerli da parte fin quando non avranno i mezzi per decriptarli.

Una roadmap concreta per la sicurezza post-quantum

La strategia delineata da Google segue il solco tracciato dagli standard pubblicati nel 2024 dal National Institute of Standards and Technology che stanno diventando il punto di riferimento globale per la transizione alla crittografia resistente al quantum. L’approccio dell’azienda si fonda su tre direttrici chiave: crypto-agility, protezione delle infrastrutture condivise e accompagnamento dell’intero ecosistema verso il cambiamento.

La crypto-agility emerge come elemento centrale, poiché consente alle organizzazioni di adattare rapidamente algoritmi e protocolli man mano che gli standard evolvono. Dal momento che le tecnologie sono ancora in fase di definizione, questa capacità rappresenta una valida opzione per evitare lock-in tecnologici e vulnerabilità eventualmente generate da ritardi nell’applicazione degli algoritmi più recenti.

Parallelamente, Google ha già avviato l’introduzione di tecnologie PQC nei propri ambienti. Il futuro Android 17 integrerà la protezione delle firme digitali basata su algoritmi ML-DSA (Module-Lattice-Based Digital Signature Algorithm), affiancandosi alle iniziative già avviate su Chrome e sulle piattaforme cloud.

Dal dato all’identità: perché l’autenticazione diventa il vero fronte critico

Se finora il dibattito sulla sicurezza post-quantum si è concentrato prevalentemente sulla cifratura dei dati, il nuovo orientamento strategico mette in primo piano anche un altro elemento: l’autenticazione e le firme digitali.

In questo caso, il rischio va oltre quello del già citato “store now, decrypt later” per sfociare nella possibile compromissione sistemica dei meccanismi di fiducia digitale. Le firme digitali attuali potrebbero diventare vulnerabili, con impatti diretti su identità, transazioni e supply chain digitali.

Per questo motivo, Google ha esplicitamente rivisto il proprio threat model, suggerendo di anticipare la migrazione PQC proprio nei sistemi di autenticazione. Una scelta che riflette una crescente consapevolezza: la sicurezza futura non dipenderà solo dalla protezione dei dati, ma dalla capacità di garantire l’autenticità delle entità digitali.

Impatti operativi: tra strategia e pragmatismo

Secondo diversi esperti del settore, il percorso verso la PQC richiede una pianificazione strutturata che vede come primo passo la mappatura dell’uso della crittografia all’interno dei sistemi aziendali, per poi coinvolgere i fornitori tecnologici facendo diventare Cloud provider, vendor VPN e partner software parte integrante della transizione, soprattutto per le organizzazioni che dipendono da soluzioni di terze parti.

Accanto a questo, pratiche consolidate come l’uso di tecniche di salting robuste possono offrire un livello di protezione immediato. Aggiungere entropia ai processi crittografici aumenta significativamente il costo computazionale degli attacchi, contribuendo a guadagnare tempo prezioso in attesa di una migrazione completa verso algoritmi post-quantum.

Uno degli aspetti meno evidenti ma più rilevanti riguarda l’interoperabilità futura. Le organizzazioni che ritarderanno la transizione potrebbero trovarsi isolate rispetto a partner e supply chain che avranno già adottato standard PQC.

Inoltre, il rischio è particolarmente elevato per i sistemi che gestiscono dati sensibili con cicli di vita lunghi, come quelli in ambito sanitario, finanziario o governativo. In questi casi, la protezione deve essere garantita non solo nel presente, ma anche in un orizzonte temporale di decenni.

---

---

---

https://www.securityinfo.it/2026/03/27/google-crittografia-post-quantum-entro-il-2029-e-novita-sullautenticazione/?utm_source=rss&utm_medium=rss&utm_campaign=google-crittografia-post-quantum-entro-il-2029-e-novita-sullautenticazione

Google is expanding Search Live to more than 200 countries and territories, bringing voice and camera conversations to AI Mode globally.

The expansion is powered by Gemini 3.1 Flash Live, a new audio model that Google calls its highest-quality yet. It’s inherently multilingual, so you can speak with Search in your preferred language without switching settings.

Search Live was previously limited to the U.S.

What’s Changing

Search Live lets you talk to Google Search inside AI Mode instead of typing a query. You ask a question out loud and get an audio response, then continue with follow-ups. Web links appear on screen alongside the voice responses.

The feature also supports camera input. Point your phone at a product label or a piece of equipment and ask Search about what it sees. Google Lens users can tap a “Live” option to start a conversation about what’s in the camera view.

With today’s expansion, both voice and camera capabilities are available in every market where AI Mode is active.

The New Model

Gemini 3.1 Flash Live replaces the previous audio model powering Search Live. Google published benchmark results alongside the announcement.

Gemini Live can now follow a conversation thread for twice as long as the previous model, according to Google. Though the company didn’t specify what the previous limit was.

Beyond Search, 3.1 Flash Live is available to developers in preview through the Gemini Live API in Google AI Studio.

Why This Matters

Search Live turns search into a spoken conversation with camera input. Until now, the feature was limited to U.S. users. Today’s expansion makes it available in the markets where AI Mode is live, across more than 200 countries and territories.

There’s no public data yet on how many people use Search Live or how it affects query volume. But Google has been building toward this for the past year. The company launched Search Live in June, added video input in July, and upgraded to Gemini 2.5 Flash Native Audio in December. Each update expanded what the feature can do and who can use it.

Looking Ahead

Google didn’t announce additional Search Live features alongside this expansion. The focus is on geographic reach and the underlying model upgrade.

How the model performs in production across different languages and markets will be worth watching as adoption data becomes available.

https://www.searchenginejournal.com/google-takes-search-live-global-with-gemini-3-1-flash-live/570602/

Mar 25, 2026 Redazione Attacchi, In evidenza, News, RSS, Vulnerabilità 0

---

La vulnerabilità “PolyShell” in Magento Open Source e Adobe Commerce è passata dalla disclosure alla compromissione su larga scala in tempi estremamente rapidi: secondo Sansec, azienda specializzata in sicurezza informatica, lo sfruttamento di massa è iniziato il 19 marzo 2026, appena due giorni dopo la divulgazione pubblica, e oggi le tracce di attacco risultano presenti su circa il 56,7% degli store ancora vulnerabili.

Questa velocità è coerente con un pattern ormai ricorrente nell’e-commerce: quando un bug consente una catena semplice e automatizzabile, gli attori malevoli trasformano la scansione in infezione in poche ore, soprattutto su piattaforme diffuse e con installazioni eterogenee come Magento. Sansec, inoltre, ha pubblicato una lista di indirizzi IP utilizzati per lo scanning mirato degli shop, segnale che la fase di ricognizione e selezione delle vittime è già industrializzata.

Il cuore del problema: upload “travestito” via REST API

Dal punto di vista tecnico, PolyShell riguarda il modo in cui la REST API di Magento gestisce l’upload di file associati alle “custom options” di un articolo nel carrello. In pratica, quando una product option è di tipo file, la piattaforma può finire per accettare e processare contenuti caricati dall’utente, con il rischio che un attaccante invii un file “poliglotta”: un oggetto che appare come immagine o risorsa legittima, ma che contiene anche porzioni eseguibili o utili a innescare altre condizioni pericolose. Se la configurazione del web server e del contesto applicativo lo permette, questo meccanismo può aprire la strada a remote code execution (RCE), oppure a account takeover tramite stored cross-site scripting (XSS), sfruttando contenuti persistenti che vengono poi renderizzati o interpretati in un contesto privilegiato. In altre parole, non è “solo” un bug di input validation, ma un punto d’ingresso che, combinato con scelte di configurazione e catene note, può trasformare un e-commerce in una piattaforma di esecuzione per l’attaccante.

Patch gap e gestione del rischio: cosa sappiamo sulle correzioni

La finestra operativa degli attaccanti è stata favorita anche dal consueto problema del “patch gap” tra fix e produzione. Adobe ha indicato che una correzione è stata resa disponibile in Magento/Adobe Commerce 2.4.9-beta1 il 10 marzo 2026, ma il fix non risulta ancora arrivato ovunque, lasciando molte installazioni senza un aggiornamento “production-ready” immediato. Sul fronte ufficiale, il bollettino di sicurezza Adobe (APSB26-05) conferma l’esistenza di vulnerabilità che, se sfruttate con successo, possono portare anche a esecuzione di codice, escalation di privilegi e letture arbitrarie del file system, pur dichiarando di non essere a conoscenza di exploit in-the-wild per le vulnerabilità trattate dal bulletin. In questo scenario, la pratica difensiva più realistica non è aspettare “la patch perfetta”, ma ridurre subito l’esposizione: capire se l’istanza è raggiungibile e attaccabile via API, verificare l’eventuale presenza di anomalie in percorsi e file di upload, e potenziare telemetria e controlli attorno ai flussi di checkout.

WebRTC skimmer: esfiltrazione cifrata e anti-controlli “tradizionali”

Nel quadro degli attacchi attribuiti o sospetti legati allo sfruttamento, Sansec segnala anche la consegna di un nuovo payment-card skimmer che usa WebRTC per stabilire un canale di comunicazione e trasporto dati più elusivo rispetto ai classici beacon HTTP. L’elemento tecnico qui è importante: WebRTC può usare DataChannels su UDP con DTLS, quindi l’esfiltrazione avviene in modo cifrato e fuori dal perimetro di molti controlli pensati per traffico web “standard”, con un impatto potenziale anche su siti che applicano politiche CSP restrittive. Sansec descrive un loader JavaScript leggero che si collega a un C2 hardcoded via WebRTC, evitando il signaling tipico grazie a uno scambio SDP “forgiato”; quindi, riceve un secondo stadio sul canale cifrato e lo esegue cercando di bypassare la CSP riutilizzando un nonce già valido oppure ricorrendo a fallback più aggressivi. Per ridurre il rischio di rilevamento immediato, l’esecuzione viene posticipata con meccanismi come requestIdleCallback, spostando l’attività malevola in un momento di minore attenzione e rumore applicativo.

---

• account takeover, Adobe Commerce, attacchi in-the-wild, card skimming, checkout security, CSP bypass, DTLS, file upload, indicatori di compromissione, Magento, Magento Open Source, patch gap, payment skimmer, polyglot file, PolyShell, RCE, remote code execution, requestIdleCallback, Sansec, script nonce, sicurezza eCommerce, stored XSS, UDP, vulnerabilità REST API, WebRTC skimmer

---

---

https://www.securityinfo.it/2026/03/25/magento-sotto-attacco-polyshell-sfruttamento-di-massa-in-pochi-giorni/?utm_source=rss&utm_medium=rss&utm_campaign=magento-sotto-attacco-polyshell-sfruttamento-di-massa-in-pochi-giorni

Mar 24, 2026 Redazione In evidenza, News, RSS, Scenario 0

---

Akamai ha appena rilasciato il suo report “2026 Apps, API, and DDoS State of the Internet” dove viene messo in evidenza come la crescita dell’intelligenza artificiale stia ridefinendo le priorità della sicurezza applicativa. Il punto centrale è che le API, diventate il tessuto connettivo dei sistemi AI, si stanno trasformando nella principale superficie di attacco per i cybercriminali.

L’evoluzione osservata non riguarda solo la sofisticazione tecnica, ma anche il modello operativo degli attaccanti. Le campagne sono sempre più industrializzate, automatizzate e progettate per scalare rapidamente, colpendo le infrastrutture critiche su cui si basa la trasformazione digitale delle imprese.

L’industrializzazione degli attacchi: API, web e DDoS convergono

Uno degli elementi più rilevanti del report riguarda la convergenza delle tecniche di attacco. Non si tratta più di singoli vettori isolati, ma di operazioni coordinate. Gli attacchi moderni combinano sistematicamente abuso delle API, compromissione delle applicazioni web e DDoS Layer 7, creando campagne multi-livello in grado di colpire contemporaneamente disponibilità, integrità e costi operativi delle piattaforme.

Questa evoluzione è strettamente legata alla diffusione dell’AI anche tra gli attaccanti. L’automazione basata su modelli intelligenti consente di rendere gli attacchi più economici, ripetibili e adattivi, abbassando la barriera d’ingresso e aumentando la frequenza delle operazioni malevole.

I numeri della minaccia: crescita esponenziale e impatto sistemico

I dati raccolti da Akamai evidenziano una crescita significativa su più dimensioni. Gli attacchi DDoS Layer 7 sono aumentati del 104% negli ultimi due anni, mentre le offensive contro le applicazioni web hanno registrato un incremento del 73% tra il 2023 e il 2025. Particolarmente significativo è il dato relativo alle API: l’87% delle aziende ha segnalato almeno un incidente di sicurezza nel 2025, indicando una diffusione capillare del problema. Parallelamente, il numero medio di attacchi API giornalieri è cresciuto del 113% dall’anno precedente.

L’adozione dell’intelligenza artificiale sta accelerando la proliferazione delle API che fungono da interfaccia tra modelli, dati e servizi aziendali. Proteggere i sistemi AI significa inevitabilmente proteggere le API che li alimentano, poiché ogni interazione tra modelli e infrastruttura passa attraverso questi endpoint. Questo crea una dipendenza diretta tra innovazione e rischio.

Il problema è aggravato dal fatto che molte organizzazioni continuano a trattare separatamente la sicurezza delle applicazioni e quella delle API. Questa separazione genera lacune di visibilità che gli attaccanti sfruttano come punto di ingresso unico verso sistemi complessi e interconnessi.

Una situazione “globale” che è aggravata, secondo il report, dal cosiddetto “vibe-coding”, lo sviluppo accelerato guidato anche da strumenti di AI. La velocità di sviluppo porta spesso a configurazioni errate e vulnerabilità che raggiungono l’ambiente di produzione senza adeguati test di sicurezza, aumentando la superficie esposta.

DDoS evoluti e botnet-as-a-service: l’infrastruttura degli attaccanti

Il report evidenzia anche l’evoluzione delle infrastrutture utilizzate per gli attacchi DDoS. L’aumento del 104% degli attacchi Layer 7 è alimentato dalla diffusione di servizi DDoS-for-hire e dall’uso di script automatizzati basati su AI.

Le botnet di nuova generazione, come Aisuru e Kimbolf, rappresentano l’evoluzione delle architetture Mirai e sono oggi alla base di ecosistemi DDoS-as-a-Service, accessibili sia a gruppi criminali che ad hacktivisti.

Hacktivismo e geopolitica: la pressione sulle infrastrutture digitali

Un altro elemento chiave è la crescita dell’attività hacktivista, spesso legata a tensioni geopolitiche. Questi attori utilizzano le stesse infrastrutture e tecniche dei gruppi criminali, ma con obiettivi diversi. Le campagne DDoS guidate da motivazioni politiche stanno diventando più frequenti e mirate, colpendo infrastrutture critiche e servizi pubblici, con impatti che vanno oltre il semplice downtime.

La combinazione tra hacktivismo e strumenti automatizzati crea scenari difficili da prevedere. La disponibilità di botnet a noleggio consente di orchestrare attacchi su larga scala in tempi ridotti, amplificando l’impatto mediatico e operativo.

Verso un nuovo modello di difesa: visibilità e integrazione

L’analisi di Akamai evidenzia come la sicurezza debba evolvere per rispondere a queste nuove dinamiche. La separazione tra domini di sicurezza non è più sostenibile. Le organizzazioni devono adottare un approccio integrato che unisca visibilità su API, applicazioni e infrastrutture, eliminando le zone d’ombra sfruttate dagli attaccanti, e garantendo un controllo continuo sulle superfici esposte. Inoltre, la crescente diffusione dell’agentic AI introduce nuove sfide. I sistemi autonomi amplificano la velocità e la complessità degli attacchi, richiedendo meccanismi di difesa altrettanto dinamici e adattivi.

---

---

---

https://www.securityinfo.it/2026/03/24/api-sotto-attacco-la-sicurezza-dellai-passa-dallinfrastruttura-applicativa/?utm_source=rss&utm_medium=rss&utm_campaign=api-sotto-attacco-la-sicurezza-dellai-passa-dallinfrastruttura-applicativa

Mar 23, 2026 Giancarlo Calzetta Approfondimenti, In evidenza, News, RSS, Vulnerabilità, Vulnerabilità 0

---

Man mano che il tempo passa, i ricercatori di sicurezza prendono sempre le meglio le misure con i sistemi LLM che forniscono i servizi AI a livello  aziendale. Purtroppo, questo significa per il momento rendersi conto  che le vulnerabilità sono davvero molte e articolate. Questo articolo analizza in dettaglio le vulnerabilità emergenti nella piattaforma Amazon Web Services Bedrock, basandosi su un’analisi pubblicata da ricercatori di sicurezza e ripresa da un articolo su Hackernews. Il tema centrale è come la forte integrazione tra agenti AI e sistemi aziendali trasformi Bedrock in una superficie di attacco estesa e profondamente interconnessa, aprendo scenari di compromissione che vanno ben oltre il singolo modello.

La capacità degli agenti di interrogare sistemi come CRM, storage e servizi applicativi introduce un nuovo paradigma. Un agente AI non è più solo un componente applicativo, ma un nodo infrastrutturale con privilegi, accessi e percorsi verso asset critici, rendendo ogni configurazione errata un potenziale punto di ingresso per attaccanti avanzati.

Logging e tracciamento: una superficie di attacco invisibile

Uno dei primi vettori individuati riguarda il sistema di logging delle interazioni con i modelli. Bedrock registra ogni richiesta per finalità di auditing, ma questa funzionalità introduce un rischio significativo.

Se un attaccante ottiene accesso ai bucket S3 utilizzati per i log, può estrarre prompt e dati sensibili senza interagire direttamente con il modello, trasformando il logging in un canale di esfiltrazione passivo. Ancora più critico è lo scenario in cui l’attaccante modifica la configurazione del logging, reindirizzando i flussi verso bucket sotto il proprio controllo.

In parallelo, la possibilità di eliminare log tramite permessi come s3:DeleteObject o logs:DeleteLogStream consente di cancellare le tracce di attività malevole. La combinazione di esfiltrazione e cancellazione delle evidenze crea una condizione ideale per attacchi stealth difficilmente rilevabili.

Knowledge Base: accesso diretto ai dati e compromissione delle credenziali

Le Knowledge Base di Bedrock rappresentano uno dei punti più critici, poiché collegano i modelli AI ai dati aziendali attraverso architetture RAG.

Un attaccante con accesso diretto alle sorgenti dati può bypassare completamente il modello e accedere ai dati grezzi, sfruttando permessi come s3:GetObject. Questo consente di aggirare qualsiasi logica di controllo applicata a livello di AI.

Ancora più pericoloso è il recupero delle credenziali utilizzate per integrare sistemi esterni come SharePoint o Salesforce. L’accesso a questi secret permette movimenti laterali verso ambienti enterprise, inclusi directory service come Active Directory, ampliando drasticamente la superficie di compromissione.

Data store e vector database: il punto debole delle credenziali

Una volta che i dati sono ingestiti, vengono archiviati in sistemi strutturati o vector database. In questo contesto, la sicurezza si sposta sulle credenziali e sulla configurazione degli endpoint.

L’accesso ai parametri di configurazione tramite API come bedrock:GetKnowledgeBase consente di recuperare chiavi API e endpoint dei database vettoriali, ottenendo accesso amministrativo completo. Questo vale per piattaforme come Pinecone o Redis Enterprise Cloud.

Nel caso di database gestiti come Aurora o Redshift, la compromissione delle credenziali consente l’accesso diretto a dataset strutturati. La violazione del data store trasforma l’intero sistema di knowledge retrieval in un vettore di esposizione massiva dei dati aziendali.

Agenti AI: orchestratori che possono essere dirottati

Gli agenti rappresentano il cuore operativo di Bedrock, orchestrando task complessi e interagendo con sistemi esterni. Questa centralità li rende un obiettivo privilegiato.

Permessi come bedrock:UpdateAgent consentono di modificare il prompt di base, inducendo l’agente a rivelare informazioni interne o comportarsi in modo malevolo, mentre la creazione di action group consente di collegare esecutori non autorizzati.

Gli attacchi indiretti risultano ancora più insidiosi. Modificando il codice di funzioni Lambda associate agli agenti, un attaccante può inserire payload malevoli. Questo approccio consente di manipolare le operazioni dell’agente dall’interno, trasformando strumenti legittimi in veicoli di esfiltrazione o sabotaggio.

Workflow e orchestrazione: manipolazione dei flussi applicativi

Bedrock Flows definiscono la logica operativa delle applicazioni AI. Intervenire su questi flussi significa alterare direttamente il comportamento dei sistemi.

Un attaccante può inserire nodi aggiuntivi nei workflow, come storage S3 o funzioni Lambda, per intercettare dati in transito senza interrompere il funzionamento dell’applicazione, rendendo l’attacco invisibile agli utenti.

La manipolazione dei nodi di condizione consente inoltre di bypassare controlli di autorizzazione. Questo permette a richieste non autorizzate di raggiungere sistemi downstream, compromettendo l’integrità dei processi aziendali.

Un ulteriore vettore riguarda la gestione delle chiavi di cifratura. Sostituendo le chiavi gestite dal cliente, un attaccante può controllare la cifratura dei dati futuri. La compromissione del sistema di encryption introduce un rischio persistente e difficilmente individuabile.

Guardrail e sicurezza del modello: degradazione controllata delle difese

I guardrail rappresentano il principale meccanismo di difesa contro contenuti malevoli, prompt injection e fuga di dati sensibili.

Attraverso permessi di modifica, un attaccante può ridurre progressivamente l’efficacia dei filtri, abbassando soglie e rimuovendo restrizioni, rendendo il modello più vulnerabile a manipolazioni.

Nel caso più estremo, la rimozione completa dei guardrail espone il sistema a comportamenti non controllati. La degradazione delle difese trasforma il modello in un vettore attivo di attacco, capace di generare contenuti pericolosi o esfiltrare informazioni.

Prompt management: compromissione su larga scala

La gestione centralizzata dei prompt introduce un ulteriore livello di rischio. I template sono utilizzati trasversalmente da agenti e applicazioni.

La modifica di un prompt condiviso consente di alterare il comportamento dell’intero sistema AI senza necessità di redeployment, rendendo l’attacco immediato e difficile da rilevare.

Attraverso prompt malevoli, un attaccante può inserire istruzioni persistenti, come la divulgazione di dati o l’inserimento di contenuti fraudolenti. La propagazione automatica di prompt compromessi può portare a esfiltrazioni massicce e a comportamenti anomali su larga scala.

Il vero problema: permessi e integrazione, non il modello

L’analisi evidenzia un pattern comune a tutti i vettori. Gli attacchi non colpiscono direttamente il modello, ma l’ecosistema che lo circonda.

Una singola identità con privilegi eccessivi può essere sufficiente per compromettere log, agenti, workflow e sistemi integrati, dimostrando come la sicurezza dell’AI sia strettamente legata alla gestione delle identità e delle configurazioni.

Per i team di sicurezza, questo implica un cambio di paradigma. La protezione delle piattaforme AI richiede visibilità completa su permessi, integrazioni e percorsi di attacco che attraversano ambienti cloud e on-premises, andando oltre i controlli tradizionali focalizzati sulle applicazioni.

---

---

---

https://www.securityinfo.it/2026/03/23/aws-bedrock-otto-vettori-che-trasformano-lai-in-un-punto-dingresso/?utm_source=rss&utm_medium=rss&utm_campaign=aws-bedrock-otto-vettori-che-trasformano-lai-in-un-punto-dingresso

Mar 19, 2026 Redazione Approfondimenti, In evidenza, News, RSS, Scenari, Scenario, Scenario 0

---

Secondo un’analisi condotta da HWG Sababa e presentata all’interno del Rapporto Clusit 2026, emerge un quadro estremamente dettagliato e critico sullo stato della sicurezza nei sistemi industriali italiani. I dati, raccolti tra ottobre 2024 e ottobre 2025 attraverso attività di gap analysis e risk assessment lungo l’intera supply chain OT, delineano un ecosistema ancora fragile, in cui le vulnerabilità non sono solo tecnologiche ma profondamente organizzative.

L’indagine coinvolge asset owner, system integrator e vendor tecnologici, offrendo una visione trasversale che evidenzia come le debolezze principali siano radicate nei modelli di governance, nei processi e nell’integrazione tra IT e OT, più che nei singoli strumenti di sicurezza.

Settori più attivi: compliance normativa come driver principale

Uno dei dati più significativi riguarda la distribuzione del numero di assessment di sicurezza effettuati nei diversi comparti industriali. Il settore Energy rappresenta il 35% dei casi analizzati, seguito da logistica e trasporti con il 21% e dal manifatturiero con il 17%. Questa concentrazione non è casuale. I settori maggiormente coinvolti sono quelli più esposti agli obblighi normativi europei, in particolare alla Direttiva NIS2, al Cyber Resilience Act e al Regolamento Macchine. Il dato suggerisce che la spinta principale verso l’adozione di pratiche di cybersecurity deriva ancora dalla compliance piuttosto che da una reale maturità della gestione del rischio.

Segmentazione IT/OT, governance e incident response

Sul piano tecnico, oltre il 50% delle organizzazioni dichiara di aver introdotto una separazione tra rete IT e rete OT. Tuttavia, nella maggior parte dei casi, tale separazione non è accompagnata da una segmentazione completa. La situazione evidenzia un gap architetturale significativo. La semplice separazione logica non è sufficiente a garantire sicurezza, se non è supportata da controlli granulari e da una gestione rigorosa delle comunicazioni tra domini. Dal punto di vista della governance, i dati più critici emergono sul piano organizzativo. Poco più del 10% delle aziende dispone di ruoli e responsabilità formalizzati per la cybersecurity OT, e una percentuale analoga adotta processi strutturati di gestione del rischio. La mancanza di governance si traduce in una difficoltà nel coordinare attività, priorità e investimenti. Senza una chiara attribuzione di responsabilità, la sicurezza resta frammentata e inefficace, soprattutto in ambienti complessi come quelli industriali. Un altro dato particolarmente rilevante riguarda la gestione degli incidenti. Solo il 20% degli asset owner dispone di un piano di incident response specifico per ambienti OT, mentre appena il 5% effettua test periodici.

Maturità cyber e pressione normativa: un equilibrio ancora instabile

Come questi dati dimonstrano, l’aumento della consapevolezza dovuto all’evoluzione normativa europea si scontra ancora con un livello di maturità complessiva molto limitato. I dati mostrano che le organizzazioni stanno avviando percorsi di assessment, ma non hanno ancora raggiunto un livello adeguato di strutturazione dei processi e dei controlli. La pressione normativa rappresenta quindi un’opportunità ma anche una sfida. Le aziende devono trasformare gli obblighi di compliance in leve di miglioramento reale della sicurezza, evitando approcci superficiali o puramente documentali perché, ricordiamocelo, i criminali non si fermano con i fogli di carta.

---

---

---

https://www.securityinfo.it/2026/03/19/la-cybersecurity-ot-in-italia-tra-maturita-limitata-e-pressioni-normative/?utm_source=rss&utm_medium=rss&utm_campaign=la-cybersecurity-ot-in-italia-tra-maturita-limitata-e-pressioni-normative