CVE-2026-102527 in og-image
Summary
by MITRE • 10/15/2026
Nuxt OG Image generates OG Images with Vue templates in Nuxt. From 6.2.5 until 6.7.0, the dynamic /_og/d/*.png route accepts unsigned requests while resolvePathCacheKey() produces cache keys from the request path, site URL, and normalized rendering options exposed through image URLs and server responses. An unauthenticated attacker can provide attacker-controlled image data through the title parameter together with a derived cacheKey and populate the cache slot used for a legitimate Open Graph image, causing spoofed image content to be served to users. This issue is fixed in version 6.7.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in Nuxt OG Image versions ranging from 6.2.5 through 6.7.0 represents a critical flaw in the application's caching and request validation mechanisms, specifically within the dynamic route responsible for generating Open Graph images at /_og/d/*.png. This component is designed to accept Vue templates as input parameters to dynamically render social media preview images based on user-provided data such as titles or descriptions. The core technical deficiency lies in the resolvePathCacheKey function, which constructs cache keys using a combination of the request path, site URL, and normalized rendering options derived directly from image URLs and server responses. Crucially, this process fails to implement any form of cryptographic signature verification or integrity check on incoming requests before they are processed for caching purposes. This absence of authentication allows unauthenticated actors to manipulate the input parameters without restriction, bypassing standard security controls that would typically validate the source or legitimacy of such dynamic content generation requests.
The operational impact of this flaw is significant due to the interaction between the unsigned request handling and the cache storage mechanism. An attacker can craft a specific URL containing maliciously controlled image data within the title parameter while simultaneously calculating or deriving the corresponding correct cache key that matches what the system expects for legitimate traffic. By submitting this crafted request, the attacker forces the application to render an arbitrary payload as if it were a standard Open Graph image and stores this result in the shared cache slot intended for valid content. Consequently, subsequent requests from other users targeting the same or similar endpoints will retrieve the poisoned cached response rather than generating fresh, legitimate images. This results in the widespread distribution of spoofed image content across the application's social sharing metadata, potentially facilitating phishing campaigns where attackers can embed malicious visual cues or deceptive branding into shared links that appear to originate from a trusted domain.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-798 Use of Hard-coded Credentials if one considers the implicit trust placed in unsigned inputs as a form of credential bypass, though it is more accurately categorized under CWE-524 Use of Cache Mechanism Containing Sensitive Information when considering the cache poisoning aspect. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1078 Valid Accounts if we consider the exploitation of valid system processes without proper authorization checks, but more precisely it falls under T1496 Resource Hijacking or potentially T1539 Steal Web Session Cookie if session data were involved, though here it is primarily a Cache Poisoning scenario which relates to T1078. The lack of input sanitization and the direct use of user-supplied data in cache key generation creates an environment ripe for injection attacks that compromise data integrity rather than just confidentiality or availability.
Mitigation strategies must focus on both immediate patching and architectural improvements. The primary remediation is upgrading to version 6.7.0 where this issue has been resolved by the maintainers, likely through the implementation of signed requests or stricter input validation protocols. For environments unable to upgrade immediately, administrators should consider implementing a reverse proxy configuration that restricts access to the /_og/d/ route to known internal IPs if possible, although this may not be feasible for public-facing services. Additionally, developers should review any custom implementations of cache key generation to ensure they incorporate unique identifiers or signatures that prevent attackers from predicting or manipulating cache slots. It is also advisable to implement Content Security Policy headers and output encoding on all dynamic content rendered through these endpoints to mitigate the risk of cross-site scripting if the image data contains executable script elements, although the primary vector here remains visual spoofing via cache poisoning rather than direct code execution.