Sysdig's threat research team published a detailed breakdown of JADEPUFFER, an agentic AI system that executed a complete ransomware campaign with no human operator involvement after initial target selection.

The attack chain: CVE-2025-3248 (Langflow RCE) for initial access, credential harvesting across LLM providers and cloud platforms, MinIO default credential exploitation, then lateral movement to a Nacos configuration server via CVE-2021-29441 (auth bypass) and JWT forgery using the well-known default signing key.

The interesting part is the self-correction behavior. When a bcrypt hash generation failed due to a PATH issue in the container, the agent diagnosed the failure, generated two hypotheses, tested both, and deployed a fix in 31 seconds. Sysdig's telemetry timeline shows the full correction chain.

Then it got worse. CSA documented ENCFORGE, a JADEPUFFER variant that specifically targets ML model files (.safetensors, .gguf, .pt, .faiss, .parquet). Destruction-first ransomware. No leak site. Leverage comes from model reconstruction costs ($75K-$500K per model).

Wrote up the full attack chain, the autonomous behavior markers, and practical defenses for self-hosted AI infrastructure:

https://medium.com/@neonmaxima/jadepuffer-is-the-first-autonomous-ai-ransomware-encforge-makes-it-worse-dcb569a11502

Impact This is a high priority vulnerability and users must upgrade ASAP.

The signature component of the authorization may be invalid, which would mean that as a client you can use any arbitrary secret to upload objects given the user already has prior WRITE permissions on the bucket,

Prior knowledge of access-key, and bucket name this user might have access to - and an access-key with a WRITE permissions is necessary.

However with relevant information in place, uploading random objects to buckets is trivial and easy via curl

Patches Yes https://github.com/minio/minio/pull/21103

Workarounds Reject requests with x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER for now at LB layer, ask application users to use STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER

Summary When someone creates an access key, it inherits the permissions of the parent key. Not only for s3: actions, but also admin: actions. Which means unless somewhere above in the access-key hierarchy, the admin rights are denied, access keys will be able to simply override their own s3 permissions to something more permissive.

Credit to @xSke for sort of accidentally discovering this. I only understood the implications.

Details / PoC We spun up the latest version of minio in a docker container and signed in to the admin UI using the minio root user. We created two buckets, public and private and created an access key called mycat and attached the following policy to only allow access to the bucket called public.

json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:" ], "Resource": [ "arn:aws:s3:::public", "arn:aws:s3:::public/" ] } ] } We then set an alias in mc: mcli alias set vuln http://localhost:9001 mycat mycatiscute

And checked whether policy works: A ~/c/minio-vuln mcli ls vuln [0001-01-01 00:53:28 LMT] 0B public/ Looks good, we believe this is how 99% of users will work with access policies.

If I now create a file full-access-policy.json: json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:" ], "Resource": [ "arn:aws:s3:::" ] } ] } And then:

sh A ~/c/minio-vuln mcli admin user svcacct edit --policy full-access-policy.json vuln mycat Edited service account mycat successfully. mycat has escalated its privileges to get access to the entire deployment: sh A ~/c/minio-vuln mcli ls vuln [0001-01-01 00:53:28 LMT] 0B private/ [0001-01-01 00:53:28 LMT] 0B public/

Impact A trivial privilege escalation unless the operator fully understands that they need to explicitly deny admin actions on access keys.

Patched

commit 0ae4915a9391ef4b3ec80f5fcdcf24ee6884e776 (HEAD -> master, origin/master) Author: Aditya Manthramurthy <donatello@users.noreply.github.com> Date: Wed Jan 31 10:56:45 2024 -0800

fix: permission checks for editing access keys (#18928) With this change, only a user with UpdateServiceAccountAdminAction permission is able to edit access keys. We would like to let a user edit their own access keys, however the feature needs to be re-designed for better security and integration with external systems like AD/LDAP and OpenID. This change prevents privilege escalation via service accounts.

Impact An attacker can use crafted requests to bypass metadata bucket name checking and put an object into any bucket while processing PostPolicyBucket. To carry out this attack, the attacker requires credentials with arn:aws:s3::: permission, as well as enabled Console API access.

Patches commit 67f4ba154a27a1b06e48bfabda38355a010dfca5 Author: Aditya Manthramurthy <donatello@users.noreply.github.com> Date: Sun Mar 19 21:15:20 2023 -0700

fix: post policy request security bypass (#16849)

Workarounds Browser API access must be enabled turning off MINIOBROWSER=off allows for this workaround.

References The vulnerable code: go // minio/cmd/generic-handlers.go func setRequestValidityHandler(h http.Handler) http.Handler { return http.HandlerFunc(func(w http.ResponseWriter, r http.Request) { // ... // For all other requests reject access to reserved buckets bucketName, := request2BucketObjectName(r) if isMinioReservedBucket(bucketName) || isMinioMetaBucket(bucketName) { if !guessIsRPCReq(r) && !guessIsBrowserReq(r) && !guessIsHealthCheckReq(r) && !guessIsMetricsReq(r) && !isAdminReq(r) && !isKMSReq(r) { if ok { tc.FuncName = "handler.ValidRequest" tc.ResponseRecorder.LogErrBody = true } writeErrorResponse(r.Context(), w, errorCodes.ToAPIErr(ErrAllAccessDisabled), r.URL) return } } // ...

Impact All users on Windows are impacted. MinIO fails to filter the \ character, which allows for arbitrary object placement across buckets. As a result, a user with low privileges, such as an access key, service account, or STS credential, which only has permission to PutObject in a specific bucket, can create an admin user.

Patches There are two patches that fix this problem comprehensively

commit b3c54ec81e0a06392abfb3a1ffcdc80c6fbf6ebc Author: Harshavardhana <harsha@minio.io> Date: Mon Mar 20 13:16:00 2023 -0700

reject object names with '\' on windows (#16856)

commit 8d6558b23649f613414c8527b58973fbdfa4d1b8 Author: Harshavardhana <harsha@minio.io> Date: Mon Mar 20 00:35:25 2023 -0700

fix: convert '\' to '/' on windows (#16852)

Workarounds There are no known workarounds

References The vulnerable code: go // minio/cmd/generic-handlers.go // Check if the incoming path has bad path components, // such as ".." and "." // SlashSeparator -> / // dotdotComponent -> .. // dotComponent -> . func hasBadPathComponent(path string) bool { path = strings.TrimSpace(path) for , p := range strings.Split(path, SlashSeparator) { switch strings.TrimSpace(p) { case dotdotComponent: return true case dotComponent: return true } } return false }

MinIO contains a vulnerability in a cluster deployment where MinIO returns all environment variables, which allows for information disclosure.

Minio is a Multi-Cloud Object Storage framework. Starting with RELEASE.2020-12-23T02-24-12Z and prior to RELEASE.2023-03-13T19-46-17Z, a user with consoleAdmin permissions can potentially create a user that matches the root credential accessKey. Once this user is created successfully, the root credential ceases to work appropriately. The issue is patched in RELEASE.2023-03-13T19-46-17Z. There are ways to work around this via adding higher privileges to the disabled root user via mc admin policy set.

Minio is a Multi-Cloud Object Storage framework. Affected versions do not correctly honor a Deny policy on ByPassGoverance. Ideally, minio should return "Access Denied" to all users attempting to DELETE a versionId with the special header X-Amz-Bypass-Governance-Retention: true. However, this was not honored instead the request will be honored and an object under governance would be incorrectly deleted. All users are advised to upgrade. There are no known workarounds for this issue.

MinIO is a High Performance Object Storage released under GNU Affero General Public License v3.0. In affected versions all 'admin' users authorized for admin:ServerUpdate can selectively trigger an error that in response, returns the content of the path requested. Any normal OS system would allow access to contents at any arbitrary paths that are readable by MinIO process. Users are advised to upgrade. Users unable to upgrade may disable ServerUpdate API by denying the admin:ServerUpdate action for your admin users via IAM policies.

MinIO is a multi-cloud object storage solution. Starting with version RELEASE.2019-09-25T18-25-51Z and ending with version RELEASE.2022-06-02T02-11-04Z, MinIO is vulnerable to an unending go-routine buildup while keeping connections established due to HTTP clients not closing the connections. Public-facing MinIO deployments are most affected. Users should upgrade to RELEASE.2022-06-02T02-11-04Z to receive a patch. One possible workaround is to use a reverse proxy to limit the number of connections being attempted in front of MinIO, and actively rejecting connections from such malicious clients.

MinIO is a High Performance Object Storage released under GNU Affero General Public License v3.0. A security issue was found where an non-admin user is able to create service accounts for root or other admin users and then is able to assume their access policies via the generated credentials. This in turn allows the user to escalate privilege to that of the root user. This vulnerability has been resolved in pull request #14729 and is included in RELEASE.2022-04-12T06-55-35Z. Users unable to upgrade may workaround this issue by explicitly adding a admin:CreateServiceAccount deny policy, however, this, in turn, denies the user the ability to create their own service accounts as well.

MinIO is a Kubernetes native application for cloud storage. Prior to version RELEASE.2021-12-27T07-23-18Z, a malicious client can hand-craft an HTTP API call that allows for updating policy for a user and gaining higher privileges. The patch in version RELEASE.2021-12-27T07-23-18Z changes the accepted request body type and removes the ability to apply policy changes through this API.

Minio is a Kubernetes native application for cloud storage. All users on release RELEASE.2021-10-10T16-53-30Z are affected by a vulnerability that involves bypassing policy restrictions on regular users. Normally, checkKeyValid() should return owner true for rootCreds. In the affected version, policy restriction did not work properly for users who did not have service (svc) or security token service (STS) accounts. This issue is fixed in RELEASE.2021-10-13T00-23-17Z. A downgrade back to release RELEASE.2021-10-08T23-58-24Z is available as a workaround.

MinIO is an open-source high performance object storage service and it is API compatible with Amazon S3 cloud storage service. In MinIO before version RELEASE.2021-03-17T02-33-02Z, there is a vulnerability which enables MITM modification of request bodies that are meant to have integrity guaranteed by chunk signatures. In a PUT request using aws-chunked encoding, MinIO ordinarily verifies signatures at the end of a chunk. This check can be skipped if the client sends a false chunk size that is much greater than the actual data sent: the server accepts and completes the request without ever reaching the end of the chunk + thereby without ever checking the chunk signature. This is fixed in version RELEASE.2021-03-17T02-33-02Z. As a workaround one can avoid using "aws-chunked" encoding-based chunk signature upload requests instead use TLS. MinIO SDKs automatically disable chunked encoding signature when the server endpoint is configured with TLS.

MinIO is an open-source high performance object storage service and it is API compatible with Amazon S3 cloud storage service. In MinIO before version RELEASE.2021-03-04T00-53-13Z it is possible to bypass a readOnly policy by creating a temporary 'mc share upload' URL. Everyone is impacted who uses MinIO multi-users. This is fixed in version RELEASE.2021-03-04T00-53-13Z. As a workaround, one can disable uploads with Content-Type: multipart/form-data as mentioned in the S3 API RESTObjectPOST docs by using a proxy in front of MinIO.

MinIO is a High Performance Object Storage released under Apache License v2.0. In MinIO before version RELEASE.2021-01-30T00-20-58Z there is a server-side request forgery vulnerability. The target application may have functionality for importing data from a URL, publishing data to a URL, or otherwise reading data from a URL that can be tampered with. The attacker modifies the calls to this functionality by supplying a completely different URL or by manipulating how URLs are built (path traversal etc.). In a Server-Side Request Forgery (SSRF) attack, the attacker can abuse functionality on the server to read or update internal resources. The attacker can supply or modify a URL which the code running on the server will read or submit data, and by carefully selecting the URLs, the attacker may be able to read server configuration such as AWS metadata, connect to internal services like HTTP enabled databases, or perform post requests towards internal services which are not intended to be exposed. This is fixed in version RELEASE.2021-01-30T00-20-58Z, all users are advised to upgrade. As a workaround you can disable the browser front-end with "MINIOBROWSER=off" environment variable.

MinIO versions before RELEASE.2020-04-23T00-58-49Z have an authentication bypass issue in the MinIO admin API. Given an admin access key, it is possible to perform admin API operations i.e. creating new service accounts for existing access keys - without knowing the admin secret key. This has been fixed and released in version RELEASE.2020-04-23T00-58-49Z.

Minio Inc. Minio S3 server version prior to RELEASE.2018-05-16T23-35-33Z contains a Allocation of Memory Without Limits or Throttling (similar to CWE-774) vulnerability in write-to-RAM that can result in Denial of Service. This attack appear to be exploitable via Sending V4-(pre)signed requests with large bodies . This vulnerability appears to have been fixed in after commit 9c8b7306f55f2c8c0a5c7cea9a8db9d34be8faa7.