EUVD-2026-88090
GHSA-r4gw-rxqg-rfvq
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach public /api/cache endpoint
-
DeliverySend request with manipulated token
-
ExploitBypass missing/unenforced auth guard
-
ExecutionInvoke cleanCache revalidation
-
ImpactDegrade site availability
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication required for critical functions
MITRE ATT&CK
1 technique across 1 tactic: Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | No special conditions on default deployments of NotionNext: in versions 4.1.0-4.9.5.2 the cache endpoint lacks a method/auth check entirely, and in 4.9.5.7-4.10.10 the guard is enforced ONLY when the CACHE_REVALIDATION_TOKEN environment variable is set - which is not the default, so default installs remain unauthenticated and exploitable remotely. The one mitigating factor is operator configuration: deployments that explicitly set CACHE_REVALIDATION_TOKEN are protected. Impact is limited to cache invalidation/availability; there is no data read or write. |
| Impact | The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L, base 6.9) describes a fully remote, unauthenticated, low-complexity flaw whose ONLY impact is availability-low - consistent with a cache-clearing/revalidation abuse rather than data disclosure or code execution. My independent 3.1 mapping (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, ~5.3) agrees: no confidentiality or integrity impact, bounded availability degradation from forced cache invalidation. There is no EPSS score, no CISA KEV listing, and no public exploit code identified at time of analysis - so this is 'no public exploit identified at time of analysis.' Despite CWE-306 (missing authentication) and a scary 'Authentication Bypass' tag, the real-world consequence is limited to performance/availability disruption on a niche open-source blog framework, not takeover. Net: a legitimately low-effort remote issue on default deployments, but LOW real priority given availability-only impact, obscure single-source (VulDB) reporting, and no exploitation signal. Note the description's version narrative is partly inconsistent (lists affected 'up to 4.10.10' yet says the guard exists from 4.9.5.7, protecting only non-default configs) - verify exact fixed version with the vendor/repo. |
| Exploit ScenarioDerived | A remote attacker sends an unauthenticated HTTP request to the /api/cache endpoint (cleanCache) of a default NotionNext deployment where CACHE_REVALIDATION_TOKEN is unset, manipulating the token argument to bypass the absent/unenforced guard and forcibly clear or revalidate the site cache. Repeated calls degrade availability by defeating caching and forcing expensive re-renders. No public exploit code is identified, but the attack is trivial given AV:N/AC:L/PR:N. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 28, 2026
Unauthenticated remote attackers can call the cleanCache handler in NotionNext's pages/api/cache.js to force cache invalidation, degrading availability for sites built on the framework. Every release from 4.1.0 through 4.10.10 is affected: versions 4.1.0-4.9.5.2 perform no HTTP method or authentication check on the endpoint at all, while 4.9.5.7-4.10.10 add a guard that is only enforced when the CACHE_REVALIDATION_TOKEN environment variable is explicitly set, so default deployments remain exposed. Impact is confined to availability (assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) with no data read or write and no code execution; no public exploit code or active exploitation has been identified at time of analysis, and the vendor was contacted but did not respond, so no fix has been confirmed.
RemediationAI
No vendor-released patch has been identified at time of analysis - the vendor was contacted about this disclosure but did not respond, so there is no confirmed fixed version to upgrade to. The most direct compensating control is to define a strong, random CACHE_REVALIDATION_TOKEN environment variable on installations running 4.9.5.7-4.10.10, which activates the built-in guard so that only callers presenting the token can clear the cache; the trade-off is that any legitimate external revalidation trigger (e.g., a Notion webhook or CI job) must be updated to send that token or it will break, and this control does nothing for the 4.1.0-4.9.5.2 range. For those older versions, first upgrade to at least 4.9.5.7 and then set CACHE_REVALIDATION_TOKEN, since the earlier releases cannot be protected by configuration alone. Where upgrading or token configuration is not possible, block or restrict access to the /api/cache path at the reverse proxy, CDN, or WAF, or allow only trusted source addresses via an IP allowlist; the trade-off is that unlisted legitimate revalidation traffic will be rejected and caching/ISR updates must be triggered another way. Removing the cache route entirely from the deployed build eliminates the exposure at the cost of losing automatic cache revalidation. Note that all of these controls reduce availability-related risk only; no data disclosure or code execution is involved. Track https://vuldb.com/vuln/410874 and the project repository for a future upstream fix, since none is confirmed at this time.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
NotionNext is a Next.js-based blogging/CMS framework that renders content from Notion and relies on API routes for ISR/cache revalidation. The vulnerable component is the API route defined in pages/api/cache.js, specifically the cleanCache function, reachable over HTTP at the deployed /api/cache endpoint. The root cause class is CWE-306 (Missing Authentication for Critical Function): the cache-clearing action is performed without verifying caller identity, and the incoming token argument is trusted or simply absent. In 4.1.0-4.9.5.2 the route lacks both an HTTP method check and any auth check, so any remote caller can trigger it; in 4.9.5.7-4.10.10 a guard was introduced but is conditional on the CACHE_REVALIDATION_TOKEN environment variable being present, which is not the default configuration, making the protection opt-in rather than built-in. The CPE cpe:2.3:a:notionnext-org:notionnext:*:*:*:*:*:*:*:* uses a wildcard, reflecting that affected version boundaries are defined by the advisory rather than a CPE version range. Because the only security-relevant effect is repeated cache invalidation and forced re-rendering (upstream Notion API calls, server load), the CVSS 4.0 vector's availability-low score is consistent with a cache-clearing abuse rather than data disclosure or remote code execution.
Know when Notionnext gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Remote unauthenticated cache-clearing endpoint on default configs gives AV:N/AC:L/PR:N/UI:N; impact is availability-only (A:L) with no confidentiality or integrity effect.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
DescriptionCVE.org
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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB