pytorch

SAAS Salesforce partners not seeing meaningful revenue from Agentforce AI platform, report saysShow us the money ai and ml AI companies are burning books, advocates complain to FTCFahrenheit 203, the temperature GPUs stop gorging on literature DEVOPS Go updates may delight diehard gophers but displease AI overlordsv 1.27 expands generics to support methods EDGE AND IOT Waymo has designed a robocar chip to stay ahead of Tesla5 nm ML accelerators promise 1,000+ TOPS, ultra-low latency SYSTEMS AMD inches closer to its goal of making AI suck less ... energyHouse of Zen claims latest systems already 4x more efficient than two years ago Security Russians are posing as Signal support to launch phishing attacksPLUS: US takes down Iranian propaganda sites; Marketing company asks 'Why Do We Have Your Information?' And more! Security Microsoft patches failed to fix on-prem SharePoint, which is now under zero-day attackPLUS: China upgrades smartphone surveillance tools; Ring eases anti-snooping stance; and more Black Hat and DEF CON DEF CON Franklin project enlists hackers to harden critical infrastructureVoting village reports have been so successful, says Jeff Moss, that the whole of DEF CON will now be included Security EQT buys majority share in Swiss cybersecurity biz AcronisWent at equivalent of $3.5B+ valuation for entire firm, though portion sold not specified Malware Month Ten years since the first corp ransomware, Mikko Hyppönen sees no end in sightOn the plus side, infosec's a good bet for a long, stable career FOSS smashed one Microsoft monopoly. After 20 years of failure, it's time to smash anotherWord up GNOME can look like Windows – and Flashback can do it without extensionsNew 'Simple-taskbar' is an option, but there's a simpler, stabler way A moment of silence, please, for the final release of Debian on x86-32New Debian versions hit FOSSland in the form of 13.6 and 12.15 Baddies caught exploiting extensions bugs with perfect 10 scores on vulnerable Joomla websitesFlaws in iCagenda, Balbooa Forms extensions can impact open source CMS that powers a million sites worldwide Frame: A new X11 server – implemented directly in assemblyJoins yserver, Phoenix, and of course XLibre – and outlier Arcan Cinnamon 6.8 will support Wayland – if you want itNext version of Linux Mint’s desktop has both kinds of display server

The JadePuffer autonomous AI agent has upgraded with custom malware called EncForge that focuses on encrypting AI assets, such as training datasets, vector databases, and model checkpoints. JadePuffer was disclosed earlier this month as an agentic threat actor (ATA) capable of running autonomously through the stages of a ransomware attack, from initial access to data encryption. Cloud security company Sysdig says that the AI agent adapted to technical difficulties in real time and optimized the intrusion mechanism to find the correct fix in less than a minute. Latest attack In a report today, Sysdig says that the attacker returned to the previously breached Langflow instance vulnerable to CVE-2025-3248 with the Go-based EncForge ransomware "built specifically for AI and machine learning (ML) infrastructure." "The binary targets approximately 180 file extensions, with a deliberately broad sweep of the modern AI/ML stack, including model checkpoints, vector databases, training datasets, and embedding indices in nearly every current format," Sysdig says. After gaining access and searching for cloud credentials, API tokens, and reachable internal services, the threat actor discovered an exposed Docker socket that provided root-level control. When the initial attempt to download the ransomware payload failed, the operator iteratively developed and deployed six Python scripts over just five minutes, with the final one (deploy.py v2) solving the delivery issues. “deploy.py v2 is the completed payload: a fully autonomous pipeline that discovers the target PID, copies ENCFORGE across the namespace boundary via procfs, runs a try-mode scan, launches the live encryption pass, and then counts .locked files to verify execution,” Sysdig explained. EncForce ransomware The Go-based binary (lockd) is packed using the Ultimate Packer for eXecutables (UPX) that targets 180 file extensions, including: AI model checkpoints Hugging Face SafeTensors files PyTorch and TensorFlow models GGUF and GGML weights FAISS vector indexes Training datasets, including Parquet, Arrow, TFRecord, NumPy, and DuckDB formats Its command-line help also uses LoRA adapters and legacy GGML files as examples of additional targets, which Sysdig sees as evidence that the ransomware was deliberately built for AI environments rather than a generic file encryptor. EncForce uses the AES-256 algorithm in counter mode to encrypt files in a hybrid scheme, where the symmetric key is secured with an RSA-2048 public key. To improve performance, the malware encrypts only selected portions of each file rather than the entire contents. Encrypted files are appended with the .locked extension, and a ransom note is dropped to notify the victim of the attack, stating that a unique identifier has been assigned. The researchers found no evidence that JadePuffer exfiltrated any data during the intrusion, and EncForge itself does not appear to include a data-stealing mechanism. Analysis of the Linux variant revealed the presence of Windows anti-recovery functions such as shadow copy deletion and boot recovery disabling. A macOS version, although hinted in the code, remains unconfirmed. Sysdig comments that encryption of model weights, training datasets, and vector indexes could cost organizations weeks or even months of training and fine-tuning, with financial damages estimated between $75,000 and $500,000 per model, depending on its size and purpose. Defense suggestions include applying available security updates, most notably Langflow version 1.3.0 or later, restricting Docket socket access, running Langflow containers as non-root, and applying filesystem-level access controls to model weight directories. 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

A malicious version of the PyTorch Lightning package published on the Python Package Index (PyPI) delivers a credential-stealing payload targeting browsers, environment files, and cloud services. The developer disclosed the supply-chain attack on April 30, saying that version 2.6.3 of the package included a hidden execution chain that downloads and executes a JavaScript payload. PyTorch Lightning is a deep learning framework used for pretraining and fine-tuning AI models. It is a popular package, amassing more than 11 million downloads last month. The security advisory from the maintainer notes that the malicious execution chain triggers automatically on import and silently spawns a background process. That process downloads a JavaScript runtime (‘Bun v1.3.13’) from GitHub, and executes a 11.4 MB heavily obfuscated JavaScript payload (‘router_runtime.js’). In a post over the weekend, Microsoft Threat Intelligence says that Defender detected and prevented the malicious routine on customer environments, and notified the package maintainer. The payload, which Defender detects as “ShaiWorm,” is an information-stealing malware that targets .env files, API keys, secrets, GitHub tokens, and data stored in Chrome, Firefox, and Brave browsers. It also interacts with cloud service APIs (AWS, Azure, GCP) to steal credentials and supports arbitrary system command execution. “lightning==2.6.3 (published on PyPI as py3-none-any wheel) contains a hidden execution chain that silently downloads a JavaScript runtime (Bun) and executes an 11.4 MB heavily obfuscated JavaScript payload upon import lightning,” Lightning AI says in the security advisory. “This payload contains credential-stealing functionality targeting cloud providers, browsers, and environment files.” According to Microsoft's telemetry, the malicious activity affected "a small number of devices" and appears to have been "contained to a narrow set of environments." Lightning AI warns that users who ran ‘import lightning’ with version 2.6.3 may have had their secrets, keys, and tokens compromised. In this case, an immediate rotation of all secrets is strongly recommended. Currently, PyTorch Lightning has been reverted to 2.6.1 on PyPi, which is safe to use. At this time, it is unclear exactly how the supply-chain compromise occurred, and the package's publishers are currently investigating how the build/release pipeline was breached. Additionally, all other recent releases will be audited for similar payloads, and users will be notified via all available channels. 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

In yet another software supply chain attack, threat actors have managed to compromise the popular Python package Lightning to push two malicious versions to conduct credential theft. According to Aikido Security, OX Security, Socket, and StepSecurity, the two malicious versions are versions 2.6.2 and 2.6.3, both of which were published on April 30, 2026. The campaign is assessed to be an extension of the Mini Shai-Hulud supply chain incident that targeted SAP-related npm packages on Wednesday. As of writing, the project has been quarantined by the administrators of the Python Package Index (PyPI) repository. PyTorch Lightning is an open-source Python framework that provides a high-level interface for PyTorch. The open-source project has more than 31,100 stars on GitHub. "The malicious package includes a hidden _runtime directory containing a downloader and an obfuscated JavaScript payload," Socket said. "The execution chain runs automatically when the lightning module is imported, requiring no additional user action after installation and import." The attack chain paves the way for a Python script ("start.py"), which downloads and executes the Bun JavaScript runtime, and then uses it to run an 11MB obfuscated malicious payload ("router_runtime.js") with an aimto conduct comprehensive credential theft. From among the harvested credentials, the GitHub tokens are validated against the "api.github[.]com/user" endpoint before being used to inject a worm-like payload to up to 50 branches retrieved from every repository the token can write to. "The operation is an upsert: it creates files that do not yet exist and silently overwrites files that do," Socket added. "No pre-check for existing content is performed. Every poisoned commit is authored using a hardcoded identity designed to impersonate Anthropic's Claude Code." Separately, the malware implements an npm-based propagation vector that modifies the developer's local npm packages with a postinstall hook in the "package.json" file to invoke the malicious payload, increases the patch version number, and repacks the .tgz tarballs. Should the unsuspecting developer publish the tampered packages from their local environment, they are made available on npm, from where the malware ends up on downstream user systems. The maintainers of the project have acknowledged that "we are aware of the issue and are actively investigating." It's currently not clear how the incident occurred, but indications are that the project's GitHub account has been compromised. In a separate advisory, Lightning revealed an investigation is still underway to determine the exact root cause of the compromise and that the "affected versions have introduced functionality consistent with a credential harvesting mechanism." In the interim, it's advised to block Lightning versions 2.6.2 and 2.6.3 and remove them from developer systems, if already installed. It's also essential to downgrade to the last known clean version, 2.6.1, and rotate credentials exposed in affected environments. The supply chain attack is the latest addition to a long list of compromises carried out by a threat actor known as TeamPCP, which has now launched an onion website on the dark web after its account was suspended from X for violating the platform's rules. It also called LAPSUS$, a "good partner of ours and has been involved heavily throughout this entire operation." The group also made it a point to emphasize that it has "never used VECT encryption tools and we own CipherForce, our own private locker," following a report from Check Point Research about vulnerabilities discovered in the ransomware's encryption process. Intercom npm and Packagist Packages Compromised as Part of Mini Shai-Hulud In a related development, it has emerged that version 7.0.4 of intercom-client has been compromised as part of the Mini Shai-Hulud campaign, following a similar modus operandi as that of the SAP packages to trigger the execution of a credential-stealing malware using a preinstall hook. "The overlap is significant because the SAP CAP campaign was linked to TeamPCP activity based on shared technical details, including distinctive payload implementation patterns, GitHub-based exfiltration, credential harvesting across developer and CI/CD environments, and similarities to prior attacks affecting Checkmarx, Bitwarden, Telnyx, LiteLLM, and Aqua Security Trivy," Socket said. It has since been confirmed that the GitHub user "nhur" was hacked and that the malicious [email protected] package was published through a now-deleted branch that triggered an automated CI publish workflow.In tandem, the campaign has also spread to Packagist with the compromise of "intercom/intercom-php" (version 5.0.2), which adapts the same credential-stealing mechanism for the PHP ecosystem. Specifically, the package uses Composer plugin execution to download Bun by means of a shell script ("setup-intercom.sh") that's triggered during install or update events (via the "post-install-cmd" and "post-update-cmd" hooks) and launches an obfuscated "router_runtime.js" credential-stealing payload. The malware component, as before, targets GitHub, npm, SSH keys, cloud credentials, Kubernetes, Vault, Docker credentials, .env files, and other developer/CI secrets. The stolen data is then encrypted and exfiltrated to a remote server ("zero.masscan[.]cloud:443/v1/telemetry"). If this primary method fails, it falls back to the GitHub-based exfiltration method using the pilfered GitHub tokens by creating a public repository with the description "A Mini Shai-Hulud has Appeared." It also comes fitted with propagation capabilities, abusing the discovered npm tokens to modify and republish packages containing the malware, in addition to writing the payload files to paths like ".claude/settings.json" and ".vscode/tasks.json." "The PHP payload mirrors the broader Mini Shai-Hulud tradecraft observed across recent npm and PyPI compromises: install-time execution, Bun-based payload launch, heavily obfuscated JavaScript, credential harvesting from developer and CI/CD environments, and encrypted exfiltration," Socket said. Intercom, for its part, has traced the root cause of the compromise to a local install of "pyannote-audio," which introduced the compromised Lightning PyPI package as a transitive dependency, offering clear evidence that the newer infections are downstream effects from prior TeamPCP waves rather than entirely independent initial access events. "That makes this especially concerning because one compromised dependency can become a bridge into additional package ecosystems," Socket told The Hacker News via email. "After two solid weeks of virtually nonstop attacks, the tempo looks deliberate and sustained rather than opportunistic. The repeated use of install-time execution, Bun-based payload delivery, obfuscated 'router_runtime.js,' credential harvesting, GitHub abuse, and package/repository propagation shows a campaign built to turn one compromised developer environment into the next package compromise." Lightning PyPI Quarantine Removed The PyPI quarantine on the Lightning package has been lifted and the malicious versions 2.6.2 and 2.6.3 have been deleted. The latest safe version is 2.6.1. In a follow-up update, the package maintainers said the malicious versions were live in PyPI for 42 minutes before they were quarantined. There is no evidence that the GitHub source code repository was ever compromised. "The threat compromised our PyPI publishing channel," they added. "An attacker with access to our PyPI credentials cloned our open source code, injected a malicious payload, and pushed those tampered builds directly to PyPI as malicious versions 2.6.2 and 2.6.3, bypassing our source control entirely. Any user who pip installed or updated to either of those versions received the attacker's build, not ours." (The story was updated after publication to reflect the latest developments and include additional insights from Socket.)

PyTorch: disponibile PoC per lo sfruttamento della CVE-2025-32434 Alert AL10/260320/CSIRT-ITA Sintesi Disponibile un Proof of Concept (PoC) per la vulnerabilità CVE-2025-32434, con gravità “critica”, che riguarda un modulo presente in PyTorch, libreria per deep learning usata per sviluppare e addestrare modelli neurali in modo flessibile. Tale vulnerabilità, qualora sfruttata, potrebbe consentire ad un utente malintenzionato remoto di eseguire codice arbitrario sul sistema interessato. Tipologia Remote Code Execution Security Feature Bypass Descrizione e potenziali impatti Disponibile un Proof of Concept (PoC) per la vulnerabilità identificata tramite la CVE-2025-32434, di tipo "Remote Code Execution" e con score CVSS v3.x pari a 9.8, che riguarda un modulo di PyTorch. Nel dettaglio tale vulnerabilità, qualora sfruttata, potrebbe consentire ad un utente malintenzionato remoto di eseguire codice arbitrario sul sistema interessato tramite il caricamento di modelli opportunamente predisposti, attraverso la funzione torch.load(). Prodotti e/o versioni affette PyTorch versioni precedenti alla 2.6.0 Azioni di mitigazione Ove non già provveduto, si raccomanda l’aggiornamento alla versione della libreria più recente pubblicata dal fornitore. Si rappresenta altresì che il solo utilizzo dell’opzione “weights_only=True” indicata dal produttore, non è sufficiente in quanto la vulnerabilità risulterebbe comunque essere presente e sfruttabile.

Three critical security flaws have been disclosed in an open-source utility called Picklescan that could allow malicious actors to execute arbitrary code by loading untrusted PyTorch models, effectively bypassing the tool's protections. Picklescan, developed and maintained by Matthieu Maitre (@mmaitre314), is a security scanner that's designed to parse Python pickle files and detect suspicious imports or function calls, before they are executed. Pickle is a widely used serialization format in machine learning, including PyTorch, which uses the format to save and load models. But pickle files can also be a huge security risk, as they can be used to automatically trigger the execution of arbitrary Python code when they are loaded. This necessitates that users and organizations load trusted models, or load model weights from TensorFlow and Flax. The issues discovered by JFrog essentially make it possible to bypass the scanner, present the scanned model files as safe, and enable malicious code to be executed, which could then pave the way for a supply chain attack. "Each discovered vulnerability enables attackers to evade PickleScan's malware detection and potentially execute a large-scale supply chain attack by distributing malicious ML models that conceal undetectable malicious code," security researcher David Cohen said. Picklescan, at its core, works by examining the pickle files at bytecode level and checking the results against a blocklist of known hazardous imports and operations to flag similar behavior. This approach, as opposed to allowlisting, also means that it prevents the tools from detecting any new attack vector and requires the developers to take into account all possible malicious behaviors. The identified flaws are as follows - CVE-2025-10155 (CVSS score: 9.3/7.8) - A file extension bypass vulnerability that can be used to undermine the scanner and load the model when providing a standard pickle file with a PyTorch-related extension such as .bin or .pt CVE-2025-10156 (CVSS score: 9.3/7.5) - A bypass vulnerability that can be used to disable ZIP archive scanning by introducing a Cyclic Redundancy Check (CRC) error CVE-2025-10157 (CVSS score: 9.3/8.3) - A bypass vulnerability that can be used to undermine Picklescan's unsafe globals check, leading to arbitrary code execution by getting around a blocklist of dangerous imports Successful exploitation of the aforementioned flaws could allow attackers to conceal malicious pickle payloads within files using common PyTorch extensions, deliberately introduce CRC errors into ZIP archives containing malicious models, or craft malicious PyTorch models with embedded pickle payloads to bypass the scanner. Following responsible disclosure on June 29, 2025, the three vulnerabilities have been addressed in Picklescan version 0.0.31 released on September 9. The development comes as SecDim and DCODX detailed another high-severity security flaw in the same utility (CVE-2025-46417, CVSS score: 7.5/7.1) that could be abused to bypass the tool's blocklist and allow malicious pickle files to exfiltrate sensitive information via DNS when the model is loaded. In a hypothetical attack scenario, an attacker can repurpose legitimate Python modules like linecache and ssl to read sensitive data from files like "/etc/passwd" using "linecache.getline()" and leverage "ssl.get_server_certificate()" to transmit the data to a domain under their control. "The leaked content appears in DNS logs. Scanning this payload with Picklescan 0.0.24 returns 'no issues found,' because linecache and ssl were not on the deny-list," SecDim said. The findings illustrate some key systemic issues, including the reliance on a single scanning tool, discrepancies in file-handling behavior between security tools and PyTorch, thereby rendering security architectures vulnerable to attacks. "AI libraries like PyTorch grow more complex by the day, introducing new features, model formats, and execution pathways faster than security scanning tools can adapt," Cohen said. "This widening gap between innovation and protection leaves organizations exposed to emerging threats that conventional tools simply weren't designed to anticipate." "Closing this gap requires a research-backed security proxy for AI models, continuously informed by experts who think like both attackers and defenders. By actively analyzing new models, tracking library updates, and uncovering novel exploitation techniques, this approach delivers adaptive, intelligence-driven protection against the vulnerabilities that matter most."

Three critical zero-day vulnerabilities affecting PickleScan, a widely used tool for scanning Python pickle files and PyTorch models, have been uncovered by cybersecurity researchers. The flaws, all with a CVSS rating of 9.3, show how attackers could bypass model-scanning safeguards and distribute malicious machine learning models undetected. The JFrog Security Research Team has described the vulnerabilities in an advisory published on 2 December. Three Critical Flaws The first flaw, CVE-2025-10155, involved a simple file extension bypass. Researchers found that renaming a malicious pickle file to a common PyTorch extension, such as .bin or .pt, caused PickleScan to misclassify the file type and hand it off to PyTorch-specific parsing logic. Because the scanner prioritized extensions over content inspection, the mismatch resulted in a failed scan while PyTorch still loaded the file normally. A second issue, CVE-2025-10156, exposed a deeper gap between how PickleScan and PyTorch process ZIP archives. PickleScan depended on Python's zipfile module, which threw exceptions when encountering Cyclic Redundancy Check (CRC) errors. PyTorch ignored these mismatches, so a corrupted archive containing malicious code could load successfully. Researchers demonstrated that zeroing CRC values in a PyTorch model archive caused PickleScan to fail, creating a blind spot that attackers could exploit to upload bypassed models. The third vulnerability, CVE-2025-10157, allowed attackers to evade PickleScan's blacklist of dangerous imports. Instead of referencing a flagged module directly, a malicious payload could call a subclass of that module, leading the scanner to label it only as "Suspicious." A proof-of-concept (POC) using internal asyncio classes showed how arbitrary commands could execute during deserialization while avoiding a "Dangerous" classification. The findings highlight systemic risks, including: Reliance on a single scanning tool Divergent file-handling behavior between security tools and machine learning (ML) frameworks Exposure to large-scale supply chain attacks across major model hubs The vulnerabilities were disclosed to PickleScan maintainers on June 29, 2025, and patched on September 2, 2025. JFrog recommended updating PickleScan to version 0.0.31, adopting layered defenses and shifting to safer formats such as Safetensors.

Cybersecurity researchers have uncovered critical remote code execution vulnerabilities impacting major artificial intelligence (AI) inference engines, including those from Meta, Nvidia, Microsoft, and open-source PyTorch projects such as vLLM and SGLang. "These vulnerabilities all traced back to the same root cause: the overlooked unsafe use of ZeroMQ (ZMQ) and Python's pickle deserialization," Oligo Security researcher Avi Lumelsky said in a report published Thursday. At its core, the issue stems from what has been described as a pattern called ShadowMQ, in which the insecure deserialization logic has propagated to several projects as a result of code reuse. The root cause is a vulnerability in Meta's Llama large language model (LLM) framework (CVE-2024-50050, CVSS score: 6.3/9.3) that was patched by the company last October. Specifically, it involved the use of ZeroMQ's recv_pyobj() method to deserialize incoming data using Python's pickle module. This, coupled with the fact that the framework exposed the ZeroMQ socket over the network, opened the door to a scenario where an attacker can execute arbitrary code by sending malicious data for deserialization. The issue has also been addressed in the pyzmq Python library. Oligo has since discovered the same pattern recurring in other inference frameworks, such as NVIDIA TensorRT-LLM, Microsoft Sarathi-Serve, Modular Max Server, vLLM, and SGLang. "All contained nearly identical unsafe patterns: pickle deserialization over unauthenticated ZMQ TCP sockets," Lumelsky said. "Different maintainers and projects maintained by different companies – all made the same mistake." Tracing the origins of the problem, Oligo found that in at least a few cases, it was the result of a direct copy-paste of code. For example, the vulnerable file in SGLang says it's adapted by vLLM, while Modular Max Server has borrowed the same logic from both vLLM and SGLang, effectively perpetuating the same flaw across codebases. The issues have been assigned the following identifiers - CVE-2025-30165 (CVSS score: 8.0) - vLLM (While the issue is not fixed, it has been addressed by switching to the V1 engine by default) CVE-2025-23254 (CVSS score: 8.8) - NVIDIA TensorRT-LLM (Fixed in version 0.18.2) CVE-2025-60455 (CVSS score: N/A) - Modular Max Server (Fixed) Sarathi-Serve (Remains unpatched) SGLang (Implemented incomplete fixes) With inference engines acting as a crucial component within AI infrastructures, a successful compromise of a single node could permit an attacker to execute arbitrary code on the cluster, escalate privileges, conduct model theft, and even drop malicious payloads like cryptocurrency miners for financial gain. "Projects are moving at incredible speed, and it's common to borrow architectural components from peers," Lumelsky said. "But when code reuse includes unsafe patterns, the consequences ripple outward fast." The disclosure comes as a new report from AI security platform Knostic has found that it's possible to compromise Cursor's new built-in browser via JavaScript injection techniques, not to mention leverage a malicious extension to facilitate JavaScript injection in order to take control of the developer workstation. The first attack involves registering a rogue local Model Context Protocol (MCP) server that bypasses Cursor's controls to allow an attacker to replace the login pages within the browser with a bogus page that harvests credentials and exfiltrates them to a remote server under their control. "Once a user downloaded the MCP server and ran it, using an mcp.json file within Cursor, it injected code into Cursor's browser that led the user to a fake login page, which stole their credentials and sent them to a remote server," security researcher Dor Munis said. Given that the AI-powered source code editor is essentially a fork of Visual Studio Code, a bad actor could also craft a malicious extension to inject JavaScript into the running IDE to execute arbitrary actions, including marking harmless Open VSX extensions as "malicious." "JavaScript running inside the Node.js interpreter, whether introduced by an extension, an MCP server, or a poisoned prompt or rule, immediately inherits the IDE’s privileges: full file-system access, the ability to modify or replace IDE functions (including installed extensions), and the ability to persist code that reattaches after a restart," the company said. "Once interpreter-level execution is available, an attacker can turn the IDE into a malware distribution and exfiltration platform." To counter these risks, it's essential that users disable Auto-Run features in their IDEs, vet extensions, install MCP servers from trusted developers and repositories, check what data and APIs the servers access, use API keys with minimal required permissions, and audit MCP server source code for critical integrations.

The job market is queasy and since you're reading this, you need to upgrade your CV. It's going to require some work to game the poorly trained AIs now doing so much of the heavy lifting. I know you don't want to, but it's best to think of this as dealing with a buggy lump of undocumented code, because frankly that's what is between you and your next job. Why AI should write your CV A big reason for that bias in so many AIs is they are trained on the way things are, not as diverse as we'd like them to be. So being just expensively trained statistics, your new CV needs to give them the words most commonly associated with the job you want, not merely the correct ones. That's going to take some research and a rewrite to get it looking like those it was trained to match. You need to be adding synonyms and dependencies because the AIs lack any model of how we actually do IT, they only see correlations between words. One would hope a network engineer knows how to configure routers, but if you just say Cisco, the AI won't give it as much weight as when you say both, nor can you assume it will work out that you actually did anything to the router, database or code, so you need to explicitly say what you did. Fortunately your CV does not have to be easy to read out loud, so there is mileage in including the longer versions of the names of the more relevant tools you've mastered, so awful phrases like "configured Fortinet FortiGate firewall" are helpful if you say it once, as does using all three F words elsewhere. This works well for the old fashioned simple buzzword matching still widely used. Being boring Among the many important reasons actual humans write El Reg and not AI (hallucinations, reasoning problems etc) is that generated text is by necessity boring. LLMs output the most "likely" response, not just buzzwords but the pattern they form. It follows that if you want them to match your CV as the best fit for the specification the hiring manager set as interpreted by the AI, it ought to fit the pattern it finds most familiar. Ironically, that is easiest done by using AI to help you achieve optimal dullness by telling it exactly what it wants to read, the way it wants to see it. There is even a good chance that the LLM you use is running on the same provider as the AI filter. In the new job market, fitting in with the pattern AIs are looking to find is as important as actually being able to do the job, more maybe. Obviously that means 40 million Reg readers are now going to get AIs to write tedious CVs which will train the next generation of application filters, but that's not my problem. You need to attack this from both directions, both creating new versions from scratch and getting your LLM to rewrite your CV as an "outstanding" Pytorch developer or project manager. That will make it both attractively dull and help you quickly generate multiple versions. Treat your skills as a database You also need to rewrite your own algo for building a CV. The AI will have found correlations between skills that vary from the insightful to the absurd, like how people whose CVs use the word "involved" tend not to be good at C++. Your prompts to the ChatGPT or whatever should include a list of all the skills you can credibly claim to have. Stop thinking of your CV as a Word document, and start thinking of it as a report run on the database of your skills. Include every damned language, tool, protocol, mathematical technique, certificate, line of business, skill and experience in your career and education. Then wait a few days, go back, and add some you've forgotten. Feel to repeat over a beer. Yes, this is hard work. Getting a job is itself a job. Even before AI, it was always better to tailor your application to each job and that gets tedious rather quickly, so automation is your friend here especially because… There is no perfect CV Every tip I've given you is wrong. Sorry. Because each AI filtering system is different. Putting Java 24 is often better than just Java because they seem to be impressed by numbers, but since they can't count, it may mess with a filter for "Java 21." That means you must not put all your eggs in one basket, a CV that works well for one AI may bomb at another and to add to the fun, the employer may use an agency for the first cut, which has a different AI, so there's two to deal with. Recruitment AI filters include the published job spec and you absolutely must copy out phrases from that and put them exactly as written into your CV. So if they say "architect and implement features" you say that, and not "designed and built." Yes I know these mean the same thing, so pick out those words from the specification and swap them with the words you currently have. As a headhunter I always despised the pretentious intros on some CVs of the form "a hard working professional master software engineer with a top tier education." Guess what? I'm now telling you to put this crap in. That's because the filter HR will set goes beyond the spec it publishes and includes words like "exceptional," because half the job specs I've seen have the "E" word. All the training a CV filter on recruiters databases can give you is tell you what phrases correlate with people who work in these jobs, hence the biases some people whine about with AIs filtering CVs, but let's be honest here, humans were never all that good. It's just too much to expect an MBA in HR to understand the very different skills necessary to be a security guard, configure a firewall, write secure code as well as accountancy and whatever it is that "sales enablement" do. That's on top of the hideous levels of bias against anyone over 40 and according to Youth Futures Foundation, 48 percent of young minorities have experienced discrimination, so it's hard to see AI as worse. Do I have to tell you to check the AI hasn't hallucinated? Yes. Because LLMs chuck out plausible text, it's all too easy for an extra skill or worse a nearly plausible version number like Python 5 that kills you when you turn up to meet a human. Less is no longer more The full version of my CV is eight pages. Yes. And much of it is true. Normally I've chopped it down so humans with their short attention spans could cope, but if you're serious about job hunting it is worth adding a "Skill Summary" page, based on the list I told you to compile earlier, laid out as a simple table of Skill, Where used, Expertise Level. It doesn't hurt when applications are vetted by wetware either. But writing code to parse randomly formatted text has been a pain and often gets confused. That means your CV needs to have a nice simple layout, plain text, no images or clever tricks with fonts else the ingestion code used to train the AI will mess up some of the text or lose it altogether, so the best way to test how an AI will see your CV is just to paste into a flat text editor. Opportunities Just because it's a grotesque violation of LinkedIn's T&Cs doesn't mean that the companies building AI CV filters have more respect for intellectual property than Meta who trained their AI on pirated books. That's not your problem, but it is an opportunity to read up on the profiles of people with the jobs you are going for. That will give you not only ideas about buzzwords and phrases to use, but also remind you of skills you have not thought to include. You suspect by now that I am training you in the same way the AIs are. Guilty as charged: know your enemy. There is a pitfall in this approach, that it will have to be read by a human the old fashioned way, so although it might be tempting to just have endless buzzwords, you still need to invest in quality words. If your CV does not say "business" at least three times, it is defective and mix in words like "deliver", "achieve", "reliable", "efficient", "team", and of course "quality" to comfort both wetware and AI. Why am I making you do all this work? Even if the current downturn isn't affecting you, if you're lucky enough to be getting jobs too easily, you're not getting the best jobs within your reach. That's why when I wrote Why Your Tech CV Sucks I was fine about the flames in the comments. ®

A chain of critical vulnerabilities in NVIDIA's Triton Inference Server has been discovered by researchers, just two weeks after a Container Toolkit vulnerability was identified. The Triton Inference Server is an open-source platform for running AI models on a scale. The flaws discovered by Wiz can potentially allow a remote, unauthenticated attacker to gain complete control of the server, achieving remote code execution (RCE). NVIDIA has assigned the following identifiers to this vulnerability chain: CVE-2025-23319, CVE-2025-23320 and CVE-2025-23334. The researchers noted that a successful attack could lead to: Model Theft: Stealing proprietary and expensive AI models Data Breach: Intercepting sensitive data being processed by the models, such as user information or financial data Response Manipulation: Manipulating the AI model's output to produce incorrect, biased or malicious responses Pivoting: Using the compromised server as a beachhead to attack other systems within the organization's network Wiz researchers disclosed the vulnerability chain to NVIDIA on May 15, and it was acknowledged by the tech firm on May 16. A patch for the vulnerabilities was released via an NVIDIA security bulletin on August 4. Triton Inference Server users are strongly recommended to update to the latest version. Wiz Details Attack Chain In an August 4 blog post, the Wiz Research team detailed the overview of the vulnerabilities it discovered. While the Triton architecture is designed to be a universal inference server which can deploy from any major AI framework (PyTorch, TensorFlow, etc.), the Wiz research focused on the Python backend because of its widespread usage. During Wiz’s audit of the Python backend, a flaw was identified in its error handling mechanism, leading to the disclosure of its internal IPC shared memory region's unique name. The returned error message appears as follows: {"error":"Failed to increase the shared memory pool size for key 'triton_python_backend_shm_region_4f50c226-b3d0-46e8-ac59-d4690b28b859'..."} The disclosure of this name is the first critical step in the exploit chain, as it exposes an internal component that should remain private. With the leaked name of the Python backend's internal IPC shared memory, an attacker can turn the public-facing API used in Triton against itself. An attacker can therefore call the registration endpoint with the leaked internal key. Once the server accepts it, they can craft subsequent inference requests that use this region for input or output. This provides the attacker with powerful read and write primitives into the Python backend's private memory, which also contains internal data and control structures related to its IPC mechanism, all performed through standard, legitimate API calls. Since an attacker can now alter the Python backend's shared memory, they can cause unexpected behavior in the server. This capability can be leveraged to gain full control of the server. This is the latest in a series of NVIDIA vulnerabilities disclosed by Wiz Research, including two container escapes: CVE-2025-23266 and CVE 2024-0132. Image credit: Hepha1st0s / Shutterstock.com

A newly disclosed set of security flaws in NVIDIA's Triton Inference Server for Windows and Linux, an open-source platform for running artificial intelligence (AI) models at scale, could be exploited to take over susceptible servers. "When chained together, these flaws can potentially allow a remote, unauthenticated attacker to gain complete control of the server, achieving remote code execution (RCE)," Wiz researchers Ronen Shustin and Nir Ohfeld said in a report published today. The vulnerabilities are listed below - CVE-2025-23319 (CVSS score: 8.1) - A vulnerability in the Python backend, where an attacker could cause an out-of-bounds write by sending a request CVE-2025-23320 (CVSS score: 7.5) - A vulnerability in the Python backend, where an attacker could cause the shared memory limit to be exceeded by sending a very large request CVE-2025-23334 (CVSS score: 5.9) - A vulnerability in the Python backend, where an attacker could cause an out-of-bounds read by sending a request Successful exploitation of the aforementioned vulnerabilities could result in information disclosure, as well as remote code execution, denial of service, data tampering in the case of CVE-2025-23319. The issues have been addressed in version 25.07. The cloud security company said the three shortcomings could be combined together that transforms the problem from an information leak to a full system compromise without requiring any credentials. Specifically, the problems are rooted in the Python backend that's designed to handle inference requests for Python models from any major AI frameworks such as PyTorch and TensorFlow. In the attack outlined by Wiz, a threat actor could exploit CVE-2025-23320 to leak the full, unique name of the backend's internal IPC shared memory region, a key that should have remained private, and then leverage the remaining two flaws to gain full control of the inference server. "This poses a critical risk to organizations using Triton for AI/ML, as a successful attack could lead to the theft of valuable AI models, exposure of sensitive data, manipulating the AI model's responses, and a foothold for attackers to move deeper into a network," the researchers said. NVIDIA's August bulletin for Triton Inference Server also highlights fixes for three critical bugs (CVE-2025-23310, CVE-2025-23311, and CVE-2025-23317) that, if successfully exploited, could result in remote code execution, denial of service, information disclosure, and data tampering. Trail of Bits researcher Will Vandevanter, who reported CVE-2025-23310 and CVE-2025-23311, said the issues are rooted in Triton's HTTP request handling logic that could result in a stack overflow, and ultimately trigger a segmentation fault and server crash. "The 'alloca' function allocates memory on the stack based on runtime parameters, which is dangerous when those parameters are untrusted, as it can lead to stack overflows and memory corruption," Vandevanter said. While there is no evidence that any of these vulnerabilities have been exploited in the wild, users are advised to apply the latest updates for optimal protection.