CVE-2026-65842: Server-Side Request Forgery with Response Disclosure in @platejs/docx-io

The @platejs/docx-io package, developed by udecode, is a server-side and client-side utility in the Plate rich-text editor ecosystem designed to convert HTML input into Microsoft Word (.docx) documents. In many application architectures, this process is run on the server to handle document exports or reports. To support images embedded within the rich text, the generator processes HTML <img> elements and attempts to resolve their target media resources for embedding.

Prior to version 53.3.2, the library automatically evaluated the src attribute of any <img> element. If the parsed attribute pointed to a valid remote URL, the server-side environment would perform an outbound HTTP GET request to download the image. This logic operated unconditionally, creating an unauthenticated attack surface that accepted untrusted URLs as inputs to the document parsing process.

The vulnerability is classified under CWE-918 (Server-Side Request Forgery). Unlike simple or blind SSRF vulnerabilities, this flaw results in complete response disclosure because the retrieved raw byte streams are compiled into the generated DOCX document structure. Attackers can leverage this behavior to bypass firewalls, probe internal subnets, and extract private data from cloud services or local loopback interfaces.

The root cause of this vulnerability lies in the unrestricted usage of the outbound image resolution parser inside the HTML-to-DOCX compilation workflow. When the htmlToDocxBlob() function is executed, it parses the input HTML markup and initiates the building of the document XML schemas. Two core helper modules manage this process: render-document-file.ts and xml-builder.ts.

Inside these helper modules, functions such as buildImage and buildParagraph analyze the HTML nodes. When the parser matches an <img> tag, it checks if the source matches a valid external address via an internal isValidUrl validator. If this check returns true, the application invokes the imageToBase64() function, which issues an HTTP request using the global runtime environment's standard fetch client.

The outbound HTTP client does not evaluate or sanitize the target address before execution. It does not verify whether the IP address points to local addresses (RFC 1918), loopback interfaces (e.g., 127.0.0.1), or link-local cloud instances (e.g., 169.254.169.254). Any response bytes retrieved are written directly into the document container structure without format verification.

To resolve the security risk, the maintainers implemented configuration checks in pull request #5053, introducing the allowRemoteImages parameter. This parameter is configured to default to false. By disabling remote image fetching, the library prevents unexpected outbound HTTP requests from occurring during document processing.

The following code snippet highlights the critical structural modifications introduced in the patch commit 21aa59926f4bbd421027354823cca09c6700ed73 inside packages/docx-io/src/lib/internal/helpers/render-document-file.ts:

export const buildImage = async (
  // ... parameters
) => {
  // ... initialization
 
-   if (imageSource && isValidUrl(imageSource)) {
+   if (
+     docxDocumentInstance.allowRemoteImages &&
+     imageSource &&
+     isValidUrl(imageSource)
+   ) {
      const base64String = (await imageToBase64(imageSource).catch(() => {})) as
        | string
        | undefined;
 
        // ... base64 encoding code
-   } else if (imageSource) {
+   } else if (imageSource?.startsWith('data:')) {
      base64Uri = decodeURIComponent(imageSource);
    }

Additionally, similar sanitization changes were implemented in packages/docx-io/src/lib/internal/helpers/xml-builder.ts to block standard URLs from initiating network fetches. The revised engine now restricts alternative image types to data-based inline URIs (e.g., data:image/png;base64,...). The parser strictly processes local base64 strings, avoiding network interaction entirely when allowRemoteImages is false.

An attacker can exploit this vulnerability by submitting an HTML payload containing a crafted <img> element to any application endpoint that converts user-provided rich text to the DOCX format. Since there is no input verification or network proxy isolating the request, the application server acts as a proxy, fetching the targeted resources within the server's network context.

The following HTTP payload example illustrates a request designed to query an internal API and extract local information:

<p>Document Header</p>
<!-- Targeted at AWS EC2 Instance Metadata Service (IMDSv1) -->
<img src="http://169.254.169.254/latest/meta-data/iam/security-credentials/" />
<!-- Targeted at internal administrative microservices -->
<img src="http://127.0.0.1:8080/admin/health" />

Upon generating the target file, the backend saves the retrieved text content as an image stream. To extract the disclosed information, the attacker downloads the generated .docx file and treats it as a standard .zip archive. Executing unzip document.docx exposes the file structure. The attacker then reads the raw content of the leaked responses by opening the compiled binary objects stored in /word/media/image1.png or /word/media/image2.png.

The impact of this vulnerability is significant, as it leads to full response disclosure. Typical blind SSRF vulnerabilities only permit an attacker to probe ports or trigger outbound requests. In this case, because the server encodes the response and returns it within the file, the attacker gains direct visibility into internal systems.

In cloud environments such as Amazon Web Services (AWS), Google Cloud Platform (GCP), or Microsoft Azure, this flaw allows attackers to access Metadata Services (IMDS). For example, querying http://169.254.169.254/ can reveal instance credentials, access tokens, and private configuration variables, which may lead to complete infrastructure compromise.

The CVSS v3.1 base score is 8.2 (High), with a High Confidentiality impact (C:H). The vulnerability requires no user interaction, zero privileges, and has low exploitation complexity, making it a viable target for unauthorized lateral movement once an attacker maps the application's document export features.

Remediation requires upgrading @platejs/docx-io to version 53.3.2 or later, which disables remote image loading by default. Developers must verify that their package management configurations are correctly updated and lock file declarations are regenerated to ensure older transitive dependencies are evicted.

# Upgrade dependency to fixed version
npm install @platejs/docx-io@53.3.2

If you must enable allowRemoteImages: true to support remote images, you must implement strong security controls. These include validating all URLs before passing them to the generator and blocking private IP space (such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, and 169.254.169.254).

Additionally, apply egress network policies at the firewall or container runtime level. This ensures that the system components executing the document generation process are network-isolated and cannot communicate with internal endpoints or sensitive metadata services.