AI data attacks corrupt systems by targeting the data a model learns from or the stored model artefact itself. They are distinct from evasion attacks (which manipulate inputs at inference time) and privacy attacks (which extract information the model has memorised). The attacks covered here work earlier in the lifecycle, corrupting the pipeline so that by the time the model serves a prediction, the damage is already inside it. This article walks through each attack type stage by stage, drawn from the AI Data Attacks module on HackTheBox Academy and grounded in the e-commerce recommendation engine and healthcare diagnostic tool examples mapped in the previous pipeline article. It connects to LLM04:2025 Data and Model Poisoning and LLM03:2025 Supply Chain in the OWASP LLM Top 10.

Attack surface overview

Every pipeline stage has a corresponding attack type. Data poisoning targets collection. Storage tampering and model replacement target stored assets. Processing manipulation targets transformation logic. Model poisoning is the inherited consequence at the modelling stage. Deployment injection intercepts model files on their way to production. Retraining exploitation feeds malicious data through the feedback loop.

The sections below walk through each one.

Data poisoning at collection

Collection is where data poisoning enters the pipeline. The attacker injects malicious data at the source, not by breaking in, but by using the same input channels the system already trusts. The injected data is crafted for a specific downstream effect, typically label flipping (changing what the model thinks a sample means) or feature attacks (perturbing the input values a sample carries).

In the e-commerce example, an attacker submits waves of fake positive reviews for a specific product. Those reviews carry the correct format, arrive through the normal review submission API, and look like legitimate user feedback. They are poisoned features and labels entering through a trusted channel. Some reviews might also contain specific keyword patterns, meaningless to a human reader but designed to function as backdoor triggers. If the model later receives an input containing those keywords, the backdoor activates and the model produces whatever output the attacker intended.

The healthcare example works differently in mechanism but follows the same principle. An attacker with access to the ingestion pathway alters DICOM metadata or manipulates clinical notes to mislabel diagnostic samples. The individual perturbations are small, a shifted pixel distribution in an image header or a swapped diagnosis code in a text note. But if enough poisoned samples reach the training set, the CNN learns a version of the diagnostic task that includes the attacker’s distortions, whether those are wrong classifications, systematic biases, or triggered behaviours that only activate under specific input conditions.

Storage-layer attacks

Storage attacks split into two categories. The first is straightforward. Unauthorised access to the S3 data lake or the healthcare provider’s encrypted storage lets an attacker steal or modify training datasets directly. Post-collection tampering such as changing labels or perturbing features in stored files bypasses whatever validation existed at ingestion. This is data poisoning through a different door.

The second category targets model files, and it is the one that carries the most severe consequences for AI-specific threats. The .pkl recommendation model on S3 and the .pt diagnostic model are high-value targets because they carry executable trust.

An attacker with write access can replace a legitimate model with one containing an embedded Trojan, a model that behaves normally on clean inputs but produces attacker-chosen outputs on trigger inputs. They can also execute a model steganography attack, hiding arbitrary code directly inside the model file. This works because deserialisation mechanisms like pickle.load() execute embedded code when they load the file.

The result is not wrong predictions. It is code execution. A compromised .pkl loaded by the Flask API server gives the attacker a foothold on the serving infrastructure. A compromised .pt loaded by the clinical system gives access to the healthcare network.

Processing-stage attacks

Processing attacks do not target data directly. They target the code that transforms data. The distinction matters because if an attacker compromises the cleaning, transformation, or feature engineering logic, they can corrupt data that was perfectly clean when it arrived. The raw data upstream still passes any audit. The corruption happens inside the pipeline’s own processing step, making it significantly harder to detect.

In the e-commerce platform, compromising the Spark job that runs sentiment analysis on reviews could flip sentiment labels, tagging positive reviews as negative and negative reviews as positive. That is a textbook label flipping attack, but it did not require touching a single raw review. It required modifying a job configuration or injecting code into a processing script.

The healthcare analogue works the same way. Manipulating the Python scripts that standardise DICOM images or extract features from clinical notes could introduce subtle errors, such as shifted pixel normalisations or misextracted text features, that constitute feature attacks. The raw images and notes remain correct in storage. The corruption exists only in the processed output the model trains on.

Inherited damage at modelling

The modelling stage is where all upstream damage materialises. The SageMaker training job does not know that the Parquet files contain flipped labels. The PyTorch training loop does not know that some image features carry backdoor triggers. Both blindly learn what the data teaches.

Poisoned data produces a poisoned model, one that has learned incorrect patterns, exhibits systematic biases, or contains hidden backdoor behaviour that activates only when specific trigger inputs appear in production. The attack surface at this stage is inherited, not introduced. The adversary’s work was done during collection, at storage, or in processing. Modelling converts that earlier corruption into a trained artefact that carries the manipulation forward into deployment.

Deployment injection

The deployment stage introduces a different attack vector, intercepting the model file between storage and the production environment. If the loading mechanism lacks integrity checks (no hash verification, no signature validation, or an insecure deserialisation path) an attacker can swap in a malicious model file at the point of deployment rather than in storage.

The outcome is the same Trojan or model steganography risk described in the storage section, but the access requirement is different. The attacker does not need direct write access to S3 or the model registry. They need access to the deployment path, whether that is a misconfigured CI/CD pipeline, an unauthenticated model-pull endpoint, or a man-in-the-middle position between storage and the serving pod.

Online poisoning through retraining

Retraining is the most effective entry point for online poisoning because the pipeline is structurally designed to trust new data.

In the e-commerce platform’s Airflow-managed retraining pipeline, the attacker does not need to compromise storage or processing code. They submit manipulated data through the same channels legitimate users do, including subtly altered clickstream data, misleading feedback that biases future labels, and repeated interactions engineered to pull model weights toward specific outcomes. Each individual submission looks normal. The poisoning accumulates across retraining cycles.

That gradual pace is what makes online poisoning hard to catch. Recommendation quality does not collapse overnight. It drifts. Biases emerge slowly across model versions, and the monitoring system has to distinguish between three things that look very similar, namely genuine distribution shift in user behaviour, random noise, and active adversarial manipulation. The system was built to adapt to the first. It has no built-in mechanism to reject the third.

Impact range

The overall impact spans a wide range. At one end, subtly biased decisions and degraded prediction quality. At the other, complete model compromise. At the worst end, when the attack involves embedded Trojans or code execution through deserialised model files, the breach extends beyond the model and into the broader infrastructure.

Mapping to security frameworks

Two security frameworks provide structured language for these risks.

OWASP LLM Top 10 2025

Data poisoning, meaning the corruption of data during collection, processing, training, or feedback, falls under the OWASP LLM04 (2025) entry for Data and Model Poisoning. That single entry captures the majority of the attacks described in this article.

The OWASP LLM03 (2025) entry for Supply Chain covers the rest. It addresses compromised third-party data sources, tampered pre-trained model artefacts, and vulnerabilities in the software components and platforms that make up the pipeline infrastructure. LLM03 extends beyond data poisoning into dependency management, third-party model provenance, and infrastructure integrity.

Google SAIF

Google’s Secure AI Framework covers the same ground from a lifecycle perspective rather than a vulnerability list.

SAIF organises its principles around secure design, data component protection, and supply chain verification. Preventing data poisoning maps to securing the data supply chain by implementing security testing during model development. This is particularly relevant for data entering through retraining loops, where the trust boundary is weakest. Model artefact integrity and code injection prevention fall under SAIF’s Secure Deployment practices. Detecting data or model manipulation hidden inside running retraining loops maps to Secure Monitoring and Response, treating security as a continuous process rather than a deployment gate.

That last point is the one that matters most for the attacks covered here. Online poisoning in particular is designed to operate within normal system behaviour. Catching it requires monitoring geared toward identifying statistical anomalies across data distributions over time. Perimeter security at deployment is not sufficient on its own.