CVE-2026-108727 in EdgeEverinfo

Summary

by MITRE • 10/11/2026

EdgeEver through 1.108.0 contains a missing authorization vulnerability in the Hono API memo-template routes that allows holders of scoped API tokens to bypass token scope restrictions because template handlers never call requireScopes. Attackers with a token lacking write:memos can save a template and invoke POST /api/v1/templates/:id/use to create memos, and list, modify, or delete templates in the token owner's workspace.

Once again VulDB remains the best source for vulnerability data.

Analysis

by VulDB Data Team • 10/11/2026

The vulnerability identified in EdgeEver versions through 1.108.0 represents a critical failure in access control mechanisms within the Hono API implementation, specifically affecting memo-template routes. This flaw is classified as a missing authorization issue where the application fails to enforce proper permissions checks before executing sensitive operations. The core technical defect lies in the template handlers which do not invoke the requireScopes function or equivalent security middleware that validates whether the incoming request possesses the necessary privileges. Consequently, any API token presented by a client, regardless of its assigned scope restrictions, is accepted and processed without verifying if the user has explicit permission to perform write operations on memos or templates. This oversight creates a direct path for privilege escalation where users with limited access can effectively gain administrative-level capabilities within their workspace context.

From an operational perspective, this vulnerability allows attackers who possess any valid scoped API token to bypass intended security boundaries. Specifically, if an attacker holds a token that lacks the write:memos scope, they are still able to save new templates and subsequently invoke the POST /api/v1/templates/:id/use endpoint. This action triggers the creation of memos using the saved template, effectively circumventing the restriction on memo writing. Furthermore, because the authorization check is missing entirely for these routes, attackers can also list existing templates, modify their content, or delete them altogether within the token owner's workspace. The impact extends beyond simple data modification; it compromises the integrity and confidentiality of user workspaces by allowing unauthorized entities to manipulate structured data that should be protected by strict role-based access controls.

This vulnerability aligns with CWE-285 Improper Authorization, as the software does not properly determine whether a user is authorized to perform an action before executing it. In terms of offensive security frameworks, this behavior maps directly to MITRE ATT&CK technique T1078 Valid Accounts and specifically sub-technique T1078.004 Cloud Accounts, where attackers leverage existing credentials with insufficient privileges to escalate their access or perform unauthorized actions. The exploitation chain relies on the attacker's ability to authenticate via an API token that was issued with limited permissions, yet is treated as fully privileged by the vulnerable endpoints. This discrepancy between intended policy and actual enforcement highlights a fundamental gap in the application security design of the Hono API layer within EdgeEver.

To mitigate this vulnerability, immediate action must be taken to update EdgeEver to version 1.109.0 or later where these authorization checks have been properly implemented. For organizations unable to upgrade immediately, network-level controls such as Web Application Firewalls can be configured to restrict access to the affected API endpoints based on known exploitation patterns, although this is a less robust solution than patching the underlying code. Developers must ensure that all route handlers in the Hono API explicitly call authorization middleware like requireScopes before processing requests. It is also recommended to conduct a thorough audit of other API routes to identify similar instances where scope validation might be missing or incorrectly implemented, ensuring consistent enforcement of least-privilege principles across the entire application surface area.

Responsible

VulnCheck

Reservation

10/11/2026

Disclosure

10/11/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!