News, updates, trends and the latest
info you need to know about IT

Overview
A heap-based buffer overflow exists in the Tight JPEG decoding component of the TightVNC Windows Viewer version 1.3.10 and affected UltraVNC Windows Viewers. An attacker controlling a malicious VNC server can trigger memory corruption by sending a specially crafted screen update. Successful exploitation can crash the viewer and may allow arbitrary code execution, although only denial of service conditions were demonstrated during testing.
Description
TightVNC and UltraVNC provide remote desktop access using the Remote Framebuffer (RFB) protocol. Their viewer applications connect to VNC servers and decode screen updates for local display. Tight encoding supports JPEG compression of image data within these updates.
The Windows viewer function DecompressJpegRect() allocates a heap buffer using a hardcoded maximum row width of 8,192 pixels but converts JPEG pixel data using the server-supplied rectangle width without adequately checking that the output fits within the buffer. A malicious server can supply an oversized Tight JPEG rectangle that causes the conversion loop to write beyond the allocated memory. In an allocation demonstrated during testing, which included 256 bytes of padding, the out-of-bounds write began at a rectangle width of 8,257 pixels.
Exploitation requires a vulnerable viewer to establish a session with an attacker-controlled or compromised VNC server and process its crafted update. The server can advertise a sufficiently large framebuffer, so checking that the rectangle fits within the advertised framebuffer does not, by itself, prevent this overflow. Authentication or transport encryption does not prevent exploitation by a malicious server participating in the session.
Impact
An attacker controlling a VNC server can corrupt heap memory in a connected vulnerable viewer, terminating the application and interrupting the remote desktop session. Memory corruption may also permit arbitrary code execution with the privileges of the user running the viewer, but only denial of service was confirmed during testing.
Solution
Review the Vendor Information section for product-specific patch information.
According to UltraVNC’s release notes, the Tight JPEG heap overflow vulnerability was addressed in version 1.8.2.8. Users should upgrade to a current supported release containing that fix, such as version 1.8.3.1.
Unfortunately, we were unable to reach TightVNC to coordinate a fix for the affected 1.3.10 Windows viewer. Users should replace affected viewers with a maintained version or an alternative solution that has been confirmed to address the vulnerability.
Until a corrected viewer is deployed, restrict connections to trusted VNC servers only. This reduces exposure but does not protect against a compromised trusted server.
Acknowledgements
Thank you to re9rch for reporting this vulnerability. This document was written by Michael Bragg.

Overview
Multiple arbitrary file read and write vulnerabilities have been identified in applications that use ImageMagick with insufficiently restrictive security policies. Collectively referred to as ImageTragick2, these issues arise when ImageMagick processes attacker-controlled SVG or PostScript content using dangerous coders or delegates permitted by its default or application-supplied configuration. An attacker who can upload an image, or otherwise cause an application to process crafted image content, may be able to read or write files accessible to the ImageMagick process. In some deployments, these capabilities may be chained to achieve arbitrary code execution, compromising the confidentiality, integrity, and availability of the affected application and host.
Description
ImageMagick is a widely used open-source image-processing suite. Web and content-management applications, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic, and Redmine, may use ImageMagick for operations such as thumbnail generation, cropping, conversion, and transformation. ImageMagick is also commonly included in containerized AI image-processing pipelines. It may operate before inference to normalize or transform inputs, or after inference to convert and prepare generated output. In these environments, images may originate not only from direct uploads but also from URLs, automated agents, datasets, model outputs, or other upstream services.
Two vulnerability variants have been identified:
Coder invocation through SVG (MSL injection)
ImageMagick’s SVG processing can allow a crafted SVG <image> element to invoke a dangerous coder through its xlink:href value, for example, by referencing an MSL: resource. ImageMagick may then interpret the referenced content as a Magick Scripting Language (MSL) script. The script can invoke additional image readers and direct attacker-controlled image data to selected filesystem paths, enabling unauthorized file access. Exploitation depends on the internal SVG coder and the required dangerous coders being available to the ImageMagick process.
Ghostscript invocation through content detection
ImageMagick’s content-based format detection may identify crafted input as PostScript and invoke Ghostscript, a separate interpreter used by ImageMagick to handle PostScript, EPS, and PDF, even when the filename or declared type suggests another format. Although Ghostscript is invoked with -dSAFER, the observed configuration permits file access within /tmp. A crafted PostScript file may therefore read or write data in that directory. This can affect applications that use shared temporary storage for uploaded files, processing artifacts, sessions, or other security-sensitive data.
These issues highlight an important aspect of ImageMagick’s security model: Behavior that can be restricted through a custom security policy is treated as a configuration issue, not a vulnerability in ImageMagick itself. Applications and distributions are therefore responsible for deploying a policy appropriate to their threat model. Many integrations, however, process untrusted content without a sufficiently restrictive policy.
Impact
An attacker who can cause an affected application to process crafted SVG or PostScript content may be able to read or write files in directory locations accessible to the ImageMagick process. In some cases, arbitrary code execution is possible when file access can be combined with writable executable content. AI-enabled services that utilize ImageMagick may face additional exposure because of untrusted image processing. In container deployments, writable host mounts, shared volumes, credentials, or inference artifacts can substantially increase the impact of a successful exploit.
Solution
Consult the Vendor Information section for product-specific updates and mitigations. Users of products that integrate ImageMagick, including Ruby on Rails, WordPress, MediaWiki, ownCloud Classic, and Redmine, should install vendor-provided updates when available. Updating ImageMagick alone may be insufficient if its security policy continues to permit dangerous coders or delegates.
Apply a custom policy.xml based on an allowlist: enable only the formats and operations the application requires, and disable unnecessary coders and delegates, including MSL, MVG, PS, EPS, and PDF. ImageMagick’s bundled secure policy template may not be sufficient for every deployment; verify the effective policy and confirm that prohibited formats are rejected.
Additional recommendations include:
– Isolate image processing: Process untrusted images in a dedicated, minimally privileged environment with restricted filesystem access. Apply the same controls to AI preprocessing and post-processing pipelines.
– Validate and constrain input: Verify file content rather than relying on filenames, extensions, or client-supplied media types.
– Monitor processing activity: Alert on ImageMagick policy violations, unexpected delegate or coder use, unusual processing failures, and unexpected file creation.
Acknowledgements
Thanks to RyotaK of GMO Flatt Security Inc. for reporting these vulnerabilities. The pwn.ai team independently discovered Variant 2 and reported it to WordPress as CVE-2026-65640. This document was written by Vijay Sarvepalli and Molly Jaconski.

Overview
The npm library promzard, versions 4.0.0 and earlier, is vulnerable to remote code execution due to direct string interpolation of context object keys, which allows unsanitized JavaScript code injection.
Description
promzard is a Node.js library designed to automate configuration workflows by evaluating template modules and generating data objects via interactive prompting. The library allows users to provide a context object ctx to expose specific data to the template module.
promzard builds an object by walking the template module for prompt() and asynchronous functions. The keys of ctx, however, are treated as raw JavaScript source code instead of inert data. The implementation performs direct string interpolation of ctx keys, without validation or sanitization, into the parameter list of a function-expression source string that is then evaluated with vm.runInThisContext(). A key containing attacker-controlled JavaScript syntax can be executed during evaluation.
Impact
An attacker capable of influencing the ctx object’s keys (e.g. via parsed configuration file, an HTTP request, or environment variables) can break out of the function parameter list and inject arbitrary JavaScript code. This results in remote code execution within the context of the Node.js process.
Solution
Unfortunately, the maintainers of promzard could not be reached to coordinate the vulnerability. The CERT/CC recommends users ensure that any data used to populate ctx is strictly validated, and that arbitrary keys should not be passed from untrusted sources.
Acknowledgements
Thanks to Abdullah Hamdan for reporting this vulnerability. This document was written by Alex Lewis.