LIVE- ColdFusion 2025.10 and 2023.21 June Security Update Released

Adobe has released ColdFusion 2025 Update 10 and ColdFusion 2023 Update 21. The releases introduce some important advancements that reinforce a clear direction: secure-by-default behavior, tighter control, and better developer governance.

Download the updates

• ColdFusion 2025 updates
• ColdFusion 2023 updates

This update focuses heavily on addressing critical security concerns while also giving developers more control over how their applications interact with external systems, attachments, and XML processing.

Security fixes and cumulative patches

Both updates address multiple vulnerabilities that could result in arbitrary code execution, privilege escalation, and security control bypass.

From an operational standpoint, this update is cumulative, which means patch adoption does not require sequential upgrades. However, teams skipping prior updates should account for behavioral changes introduced in intermediate versions, especially in areas that now enforce stricter validation.

Attachment handling: Explicit allow-listing via accept

The introduction of the accept attribute across Exchange-related tags (cfexchangemail, cfexchangecalendar, cfexchangetask, cfexchangecontact) and alignment with cfpop and cfimap formalizes attachment filtering as an application-level concern.

At runtime, accept acts as an extension-based allow list, evaluated as a comma-separated set (for example, .pdf,.txt). This shifts attachment handling away from implicit acceptance toward deterministic filtering at the tag level.

From an implementation perspective:

• Matching is performed against file extensions, not MIME types
• The evaluation occurs before attachment persistence, reducing downstream validation overhead
• It enables developers to enforce context-specific filtering policies per integration point

Filtering model: Dual-layer validation (allow list + block list)

The filtering pipeline now follows a more structured evaluation model combining:

1. Application-level allow list (accept)
2. Platform-level blocked-extension list

The resolution logic is deterministic:

• If accept is not specified, only the blocked-extension list is enforced
• If accept="*", the allow list short-circuits validation and bypasses blocked-extension checks entirely
• If a file extension is explicitly declared in accept, it acts as an authoritative override, even if the extension is present in the blocked list
• In all other cases, the file must satisfy both the allow list and block list constraints

The key implication here is that filtering is no longer purely defensive (block-based), but policy-driven, where application logic can selectively override platform defaults when required.

A JVM-level override (-Dcoldfusion.attachment.allowblockedextensions) allows reverting to legacy permissive behavior.

MCP Client: Multi-layer command authorization

NOTE: Only applies to ColdFusion 2025 Update 10

Update 10 introduces a composable authorization model for STDIO MCP server command execution.

Command execution is now governed by three independent sources:

• Server-level whitelist (security-settings.json)

  • Enforces administrator-controlled baseline restrictions
  • Deny-by-default model: commands must be explicitly enumerated

• Application-level whitelist (this.security.mcp.commandWhitelist in Application.cfc)

  • Enables per-application scoping of allowed commands

• Inline whitelist (passed in MCPClient() / MCPServer())

  • Maintains backward compatibility with existing implementations

These lists are merged at runtime using a union operation. A command is executable if it exists in at least one list.

This design introduces a federated control model, where enforcement is distributed across infrastructure and application layers. However, it is important to note that restriction requires explicit exclusion from both server and application scopes, as the model is additive rather than restrictive.

From a security perspective, this reduces the risk of arbitrary command execution while maintaining flexibility for dynamic integrations.

XML processing: Saxon feature gating via JVM flags

ColdFusion’s Saxon-based XML processing (XMLSearch, XMLTransform) now enforces feature-level restrictions using JVM flags, all disabled by default.

The newly introduced flags gate access to:

• xsl:result-document → controls file write operations
• unparsed-text() → accesses external text resources
• doc(), doc-available() → loads external XML documents
• environment-variable() → exposes runtime environment variables

These capabilities are disabled unless explicitly enabled via JVM configuration.

This has several implications:

• Prevents data exfiltration via XSLT transformations
• Blocks access to file system paths and environment variables
• Eliminates implicit trust in transformation inputs

Developers enabling these features must now explicitly evaluate the security risk vs functional requirement, making the configuration process intentional rather than implicit.

Package updates and platform consistency

The updates also include updates to multiple core packages, including administrator, ajax, exchange, feed, mail, and websocket modules.

From a runtime and deployment perspective:

• No connector reconfiguration is required
• Package updates are applied alongside the core update
• Package rollback is decoupled from core rollback and depends on minimum core dependency constraints

This ensures consistency across modules while maintaining compatibility boundaries.

Download the updates and validate them in your staging environment. If you encounter any regressions or unexpected behavior after upgrading, report them through the Adobe support channel or your standard issue-tracking process, including relevant logs and reproduction details.