they say:
A malicious dataset abused two code-execution paths in our dataset processing (a remote-code dataset loader and a template-injection in a dataset configuration) to run code on a processing worker. From there, the actor escalated to node-level access, harvested cloud and cluster credentials, and moved laterally into several internal clusters over a weekend.
and in the comments someone mentions this repository so i go and check it out and there's this PR that seems about right. so i don't know kubernetes but it seems like there was a kubernetes worker that could just run arbitrary commands on their clusters if compromised, so that's cool.
there was also this PR from 2 hours ago that "temporarily reject(s) the packaged raw Arrow builder in safe_load_dataset_builder" pending this PR in another repo that validates maliciously formed arrow IPC record batches. hmm that sounds like the code in question.
safe_load_dataset_builder was introduced here on june 11th: https://github.com/huggingface/dataset-viewer/pull/3360 in a PR that allegedly makes data loading safer and switched the repo to only using data streaming as part of a sprint that the author describes as being about loading LLM traces and streaming data shuffling.
i'm not going looking for and trying to diagnose the full template injection path, but idk at least from what I can tell, code written by AI in order to feed more data to AI at least has been busily associated with, if not introduced some vulnerability which is now being patched by flurries of more AI code being rushed through while tests keep failing. I am not so sure about their lessons learned being "make sure you have more AI to help you to understand the problems that AI creates."
