GHSA-26W7-CXV4-GFX2: Remote Code Execution in Astro via Outdated Sharp Native Dependency

The Astro web framework provides an integrated image optimization pipeline designed to automate image transformations such as resizing, cropping, and format conversion. By default, Astro utilizes the sharp library to handle high-performance image processing operations on the server side. The sharp package acts as a native Node.js addon that binds to libvips, an extremely fast image processing library, which in turn utilizes auxiliary native libraries like libheif to decode formats such as HEIF and AVIF. This architecture introduces a native, non-memory-safe attack surface into the otherwise memory-safe Node.js runtime environment.\n\nUnder default configurations, an unauthenticated remote attacker can access the image optimization endpoints exposed by an Astro application, such as the /_image path used to serve optimized media. By submitting a specially crafted AVIF file to be processed by this service, the attacker triggers native image decoding routines on the host server. Because the framework automatically handles media processing upon request, this exposes the underlying C++ libraries to arbitrary, untrusted input without prior verification of file integrity or structure.\n\nThis flaw resides in the category of native memory corruption (CWE-119) within the underlying parser libraries. When the processing library executes, it attempts to parse the structural components of the malformed AVIF image, leading to out-of-bounds memory operations or control-flow hijack. Because Astro did not restrict the resolved version of its image processing dependency, deployments were vulnerable to execution context takeover through this native attack surface.

The AVIF format relies on the ISO Base Media File Format (ISOBMFF) container standard, which structures media files as hierarchical blocks known as 'boxes'. Each box contains a size header, a type identifier, and payload data that can include nested sub-boxes representing metadata, spatial properties, and color profiles. Parsers designed to read these files must traverse the nested box structure to reconstruct the image and apply color transforms before passing raw pixel buffers to the rendering pipeline.\n\nThe root cause of this vulnerability lies in the C++ parsing logic of libheif or libvips bundled with sharp versions below 0.35.4. Specifically, the parser fails to perform strict boundary checks when processing deeply nested boxes, inconsistent container sizes, or invalid spatial transformation matrices. When processing malformed metadata fields, an integer overflow (CWE-190) occurs during the calculation of buffer offsets, which subsequently leads to a heap-based buffer overflow or a use-after-free condition during object destruction.\n\nBecause the native addon executes within the process memory space of the Node.js application, corrupting the C++ heap allows an attacker to overwrite critical control structures, such as function pointers or virtual method tables. When the execution flow eventually references these corrupted memory addresses, the program redirects execution control to attacker-controlled memory segments, achieving arbitrary code execution within the context of the hosting process.

The vulnerability in the Astro framework stems from the loose dependency declaration in its package.json manifest. Prior to the fix, the sharp optional dependency was specified as "sharp": "^0.34.0 || ^0.35.0". This range allowed package managers to resolve the dependency to older releases within the 0.34.x and 0.35.x release lines, including versions like 0.35.2 which packaged vulnerable, unpatched builds of libvips and libheif.\n\nTo resolve this issue, Astro developer Matthew Phillips committed a patch that strictly restricts the dependency range. The fix pinpoints ^0.35.4 as the minimum supported version, which forces the package manager to download a build containing patched native binary layers where the memory safety bugs in the AVIF parser are mitigated.\n\ndiff\n# File: packages/astro/package.json\n@@ -179,7 +179,7 @@\n "zod": "^4.3.6"\n },\n "optionalDependencies": {\n- "sharp": "^0.34.0 || ^0.35.0"\n+ "sharp": "^0.35.4"\n },\n "peerDependencies": {\n\n\nWhile this fix successfully prevents default installations of Astro from using vulnerable dependency versions, it relies heavily on downstream clients using updated lockfiles. If a project maintains an existing lockfile with pinned versions of 0.35.2 or lower, the vulnerable binaries will continue to be loaded until the lockfile is explicitly refreshed. The fix is structurally complete from Astro's packaging boundary, but it remains susceptible to manual resolution overrides by users.

An attacker exploits this vulnerability by transmitting a malformed AVIF image to an Astro application that has image optimization features enabled. The attack begins with the creation of an AVIF file that satisfies basic ISOBMFF structural requirements but contains conflicting size metadata fields or deeply nested box definitions. This payload is calculated to trigger an integer overflow during heap allocation calculations inside the native decoding layer.\n\nThe next step involves identifying the target exposure path, which is typically the framework's dynamic image endpoint. An attacker issues an HTTP request targeting this endpoint, specifying the URL of the malicious image as the source parameter. When the Astro server receives this request, it fetches the remote image and passes the resulting buffer to the sharp processor to execute the requested transformations.\n\nmermaid\ngraph LR\n A["Attacker"] -->|"1. HTTP Request with Malicious AVIF"| B["Astro Server /_image"] \n B -->|"2. Call sharp.metadata()"| C["sharp Node Addon"]\n C -->|"3. Call libvips / libheif APIs"| D["Native C++ Decoder"]\n D -->|"4. Memory Corruption"| E["Heap Overflow / UAF"]\n E -->|"5. Hijack Execution Flow"| F["Arbitrary Code Execution"]\n\n\nUpon processing, the native decoder processes the malformed structures and triggers the memory corruption. If the payload is engineered correctly, the heap layout can be groomed to overwrite active function pointer tables in the C++ runtime. Once hijacked, the instruction pointer is directed to execute arbitrary shellcode, granting the attacker interactive system access under the user context running the Node.js application.

The security impact of this vulnerability is critical, allowing for unauthenticated remote code execution on the underlying server hosting the Astro application. Because image processing is often handled synchronously upon incoming request parameters, an attacker does not need any authentication credentials or special access privileges to trigger the execution flow. This results in complete compromise of system confidentiality, integrity, and availability.\n\nThe vulnerability is tracked under the GitHub Advisory Database as GHSA-26W7-CXV4-GFX2, but it does not have a corresponding CVE identifier. Consequently, automated scanning tools that rely strictly on CVE records from the National Vulnerability Database (NVD) will fail to flag this issue in production environments. This increases the window of exposure for organizations that depend exclusively on traditional vulnerability intelligence streams.\n\nFurthermore, because the execution context is that of the Node.js process, an attacker who achieves code execution can read environment variables, steal database credentials, and access internal cloud metadata endpoints. If the host process is running with elevated privileges, the attacker can leverage this access to perform lateral movement across the internal network or establish persistent backdoors within the containerized infrastructure.

To fully remediate this vulnerability, organizations must upgrade the astro package to version 7.2.8 or higher. This upgrade updates the minimum dependency constraint of the sharp package to 0.35.4. It is critical to regenerate the project's lockfile to guarantee that all transitive dependencies and platform-specific native binaries are fully updated to their secure versions.\n\nbash\n# To verify the currently resolved version of sharp in your environment\npnpm why sharp\n\n# To force-update the dependency across the workspace\npnpm update sharp --recursive\n\n\nFor systems where an immediate framework upgrade is not feasible, temporary mitigation strategies can be applied to reduce the attack surface. Administrators should consider disabling AVIF format conversion in the Astro configuration and instead restricted allowed formats to less complex, memory-safe alternatives. Additionally, web application firewalls can be configured to block requests to the /_image endpoint that attempt to process external, untrusted AVIF payloads.