Dify Enterprise 3.9.13 Incorporates AnyIO Fixes; Deployments Require Image Checks

Dify released Enterprise 3.9.13 on September 23, bringing dependency fixes from the community LTS branch into enterprise deployments. The release upgrades AnyIO in the API image from 4.11.0 to 4.14.2 and updates the base image. According to Dify, it includes no database migrations or functional changes. For teams running RAG and agent workflows, the focus is on the security of existing connections and background jobs. [Release notes](https://ee.dify.ai/releases/v3.9.13/)

The AnyIO TLS vulnerability involves internationalized domain names: some connection paths use IDNA 2003 encoding, potentially allowing a valid certificate for a different domain to pass validation. However, an attack also requires the connection to have been hijacked through other means or redirected to a malicious server. These are the conditions under which the underlying library is vulnerable; the current advisories do not establish that every Dify workflow can trigger the issue, nor do they provide examples of exploitation involving Dify. [Maintainer advisory](https://github.com/agronholm/anyio/security/advisories/GHSA-82r6-8w77-94w6)

Another issue addressed by the upgrade is process pool blocking. Older versions connected worker processes’ standard error output to a pipe without continuously reading from it. If a program produced too much output, the pipe could fill up and stall the call waiting for a result. The upstream advisory describes an availability risk. Deployers should distinguish between an affected package version and an application actually reaching the relevant execution path. [Process pool vulnerability advisory](https://github.com/agronholm/anyio/security/advisories/GHSA-5p39-cfhj-2xmp)

For deployment verification, these two fixes concern the trustworthiness of remote endpoints and whether background jobs can return normally, respectively. Teams can first identify which tools access internationalized domains and which tasks use process pools, then check the actual dependency versions inside their containers. These suggested checks follow the upstream trigger conditions; normal model responses or passing general conversation tests are insufficient to confirm coverage of these paths.

The frontend also moves to Next.js 16.3.6. A public Dify commit updates both the package declarations and the lockfile, providing a reference for checking build contents. Enterprise and community releases use different version numbers, so this update should not be taken to mean that all community deployments have been patched. [LTS commit](https://github.com/langgenius/dify/commit/75bbcffec01362d7a727758ebc21ee0b490d38d6)

Official scans show no remaining critical-severity findings across the default image set, although high-severity findings remain. The optional api-insecure image is assessed separately. ChromaDB, W&B tracing, and ClickZetta remain excluded from the default API image, a restriction carried over from the previous release. Engineering teams should check the actual images, packages in virtual environments, and integration requirements, while tracking the unresolved nltk issue. The detailed API scan also includes base-image packages, so teams must determine whether those packages are present in the application’s runtime environment; vulnerability counts alone cannot establish exploitability. [Release risk notes](https://ee.dify.ai/releases/v3.9.13/), [Detailed API scan](https://ee.dify.ai/reports/v3.9.13/scout/api/)