Description

A security vulnerability has been detected in notionnext-org NotionNext up to 4.10.10. Affected by this issue is the function cleanCache of the file pages/api/cache.js of the component Authentication Guard. The manipulation of the argument token leads to missing authentication. The attack may be initiated remotely. Versions 4.1.0 - 4.9.5.2 allow unauthenticated exploitation due to missing method check. In versions 4.9.5.7 - 4.10.10 a guard present but only enforced when CACHE_REVALIDATION_TOKEN is set. Default deployments remain unprotected. The vendor was contacted early about this disclosure but did not respond in any way.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-28T06:16:31.570Z",
  "pubdate": "2026-09-28T06:16:31.570Z",
  "executiveSummary": "A critical authentication bypass vulnerability exists in NotionNext, specifically within the cache revalidation functionality of the 'pages/api/cache.js' component. This vulnerability stems from improper access control mechanisms, allowing remote attackers to trigger cache clearing operations without valid credentials.\nThe vulnerability affects NotionNext versions up to 4.10.10. Depending on the version, the flaw manifests either as a complete lack of authentication checks or as an ineffective security guard that only activates if a specific environment variable, 'CACHE_REVALIDATION_TOKEN', is explicitly defined. In default configurations, the system remains entirely unprotected.\nThe impact of this flaw allows unauthenticated remote actors to force the application to purge its cache, potentially leading to a Denial of Service (DoS) state by overwhelming backend resources or forcing redundant data fetches. Given the lack of response from the vendor, the exposure persists in standard deployments of the product.",
  "technicalDetails": "The vulnerability is located in the 'cleanCache' function within the 'pages/api/cache.js' file of the NotionNext application. The core issue is the failure to enforce mandatory authentication checks when a request is made to the cache revalidation endpoint.\nIn versions 4.1.0 through 4.9.5.2, the 'cleanCache' function executes without any verification of a user's identity or authorization. An attacker can initiate a remote request to this endpoint to flush the application's cache entries indiscriminately. Because no method check is performed, any remote actor with network visibility to the application endpoint can trigger this administrative action.\nIn later versions, specifically 4.9.5.7 through 4.10.10, the developers introduced an Authentication Guard, but its implementation is flawed due to a dependency on the environment variable 'CACHE_REVALIDATION_TOKEN'. The logic within 'pages/api/cache.js' conditionally evaluates the request token only if this environment variable is configured. If the variable is unset—which is the case in default installations—the guard is effectively bypassed or ignored, leaving the function exposed to unauthenticated execution.\nThe attack flow involves an attacker sending an HTTP request (typically a GET or POST, depending on the implementation) to the exposed '/api/cache' endpoint. Upon receiving the request, the 'cleanCache' function executes its logic. Because the input validation for the 'token' argument is either entirely missing or incorrectly handled, the function proceeds to clear the cache storage without verifying the validity of the provided credentials or checking the existence of an authorized session.\nThe impact of successful exploitation is significant. By repeatedly triggering the cache clearing mechanism, an attacker can induce a performance degradation scenario where the application is forced to perform expensive database or external API lookups for every user request, effectively resulting in an application-layer DoS. Furthermore, in environments where cache consistency is critical for security or operational integrity, the ability to manipulate cache states remotely allows for the disruption of service availability and potentially complicates incident response operations by purging diagnostic or session-related cache data."
}