EUVD-2026-99240Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessSend repeated upload API requests
-
DeliveryTemp file written before cleanup runs
-
ExploitLeaked files and descriptors accumulate
-
ExecutionDisk or FD limit exhausted
-
ImpactService denied to all users
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Incomplete cleanup
|
| Exploitation Conditions | No special configuration is required: the flaw affects default deployments of Misskey file-upload handling in versions 13.0.0 through 2025.4.1 and 2025.5.0 through 2026.7.0, and the description explicitly states it applies 'regardless of whether federation is enabled.' Exploitation targets the multipart upload path in ApiCallService, where the temporary file is written to disk before authentication, so credentials are not required. The practical limiting factor is that impact is cumulative - a single request does no harm; an attacker must send sustained/repeated uploads to exhaust storage or file descriptors - and operators who have upgraded to 2026.7.0 or who constrain disk/FD limits and request rates reduce realistic exposure. |
| Impact | The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) scores 8.7 and describes a network-reachable, low-complexity, unauthenticated flaw requiring no user interaction, with impact confined entirely to availability (VA:H; VC:N/VI:N). The source diff corroborates PR:N: the uploaded file is streamed to a temp path BEFORE token parsing and authentication occur, so even requests that ultimately fail authentication leave an uncleaned temp file - confirming unauthenticated reachability of the leak. However, no EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The input Tag 'Information Disclosure' directly contradicts both CWE-459 (Incomplete Cleanup) and the availability-only CVSS vector - this is a resource-exhaustion denial of service, not information disclosure, and that tag should not drive triage. Net: genuinely easy to trigger remotely and without credentials, but the ceiling is DoS only against a niche self-hosted fediverse product, making this a moderate operational priority rather than a critical one despite the high CVSS. Both the CVSS vector and the description otherwise agree: remote, unauthenticated, availability-impacting behavior regardless of federation. |
| Exploit ScenarioDerived | A remote attacker repeatedly submits file-upload API requests to a Misskey instance; because cleanup of the temporary file does not reliably execute after processing, each request leaks a temp file and/or file descriptor. Sustained requests accumulate until disk space or the process file-descriptor limit is exhausted, denying service to all users. No public exploit code is identified at time of analysis, but the attack requires only trivially scriptable repeated HTTP uploads given AV:N/AC:L/PR:N. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 13, 2026
Repeated multipart file uploads to Misskey servers running versions 13.0.0 through 2025.4.1, or 2025.5.0 through 2026.7.0, can exhaust server storage and file descriptors and cause a denial of service, because temporary upload files are not reliably deleted after processing. The vulnerable upload path writes the temp file to disk before authentication is performed, so unauthenticated remote attackers can trigger it, and the behaviour holds regardless of whether federation is enabled. A single request is harmless - the impact is cumulative across sustained uploads - and the issue is resolved in Misskey 2026.7.0; no public exploit code has been identified at time of analysis.
RemediationAI
Upgrade to Misskey 2026.7.0 or later - vendor-released patch: 2026.7.0 - which adds a try/finally around the upload handler so cleanup() always deletes the temporary file, per GHSA-m9xp-2fvm-pfmq and the linked commit. If immediate upgrade is not possible, apply compensating controls and accept their trade-offs: enforce per-IP and per-account rate limits on the multipart upload endpoints at the reverse proxy (mitigates request volume but can affect legitimate heavy uploaders and shared NAT users); set a hard request-body size cap at the proxy (drives oversized uploads into the truncated/413 path that already cleaned up, but rejects legitimate large media); place the Misskey temp/upload directory on a volume with a small filesystem quota or a dedicated tmpfs with an inode limit so exhaustion is contained rather than taking down the host (side effect: legitimate uploads start failing once the quota is hit); and run a scheduled job that deletes stale orphaned temporary upload files older than a few minutes, which reclaims space but does not restore the leaked file descriptors already held by the process. Operators should also monitor free disk space and open file descriptor counts on the Misskey process as detection signals, and note that federation settings do not mitigate this issue since it applies regardless of whether federation is enabled.
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
The root cause is CWE-459 (Incomplete Cleanup). Misskey's backend API dispatcher (packages/backend/src/server/api/ApiCallService.ts) streams incoming multipart request bodies to a temporary file on disk with stream.pipeline(multipartData.file, fs.createWriteStream(path)) before the bearer-token authentication step (authenticateService.authenticate) runs. In the affected code, the cleanup() routine that removes that temporary file was only invoked on the specific branch handling an over-size, truncated upload (HTTP 413), so normal completion, authentication failure, and error paths could leave the temp file behind. Because the write happens prior to authentication, the endpoint is reachable without credentials, which is consistent with the CVSS 4.0 vector AV:N/AC:L/AT:N/PR:N/UI:N and the independent CVSS 3.1 assessment of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The upstream fix wraps the entire handler body in try { ... } finally { cleanup(); }, guaranteeing temporary file removal on every exit path. The practical consequence is resource accumulation: each orphaned upload consumes disk space and open file descriptors, and enough of them degrade or halt the service. Impact is scored entirely to availability (VA:H; VC:N/VI:N), although orphaned temp files also mean attacker-supplied content persists on the filesystem - a secondary hygiene concern rather than a scored confidentiality impact.
Know when the next one hits your stack
- 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:H/SC:N/SI:N/SA:N
Temp file is written before authentication so PR:N; remote network multipart upload with no special preconditions gives AV:N/AC:L/UI:N; impact is resource-exhaustion DoS only, so C:N/I:N/A:H.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
Misskey is an open source, federated social media platform. From 13.0.0 until 2025.4.1 and from 2025.5.0 until 2026.7.0, cleanup processing may not execute during file uploads. Repeated uploads can exhaust storage or file descriptors and deny service regardless of whether federation is enabled. This issue is fixed in version 2026.7.0.
Technical POC Analysis
Evidence note: the only supplied artefact is advisory GHSA-m9xp-2fvm-pfmq.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Misskey instances running versions 13.0.0 through 2025.4.1, or 2025.5.0 through 2026.7.0, can be forced into denial of service by sustained repeated multipart file uploads that accumulate undeleted temporary files and exhaust server storage and file descriptors. Because the vulnerable upload path writes the temporary file to disk before authentication is performed, and the behavior holds regardless of whether federation is enabled, any internet-reachable instance is exposed and the damage accumulates across requests rather than requiring a single harmful request. Leadership should care because this is an availability risk to a public-facing community platform and to any other workloads sharing the same host, storage, or file-descriptor budget.
No vendor-released patch identified at time of analysis. Interim mitigations: rate-limit and size-cap multipart upload requests at the reverse proxy or WAF, enforce per-client upload concurrency limits, restrict or disable anonymous upload paths where operationally feasible, apply temporary-directory quotas with scheduled cleanup of stale upload files, monitor disk space, inode usage and file descriptor counts with alerting, and segregate Misskey instances onto dedicated storage so exhaustion cannot propagate to other systems.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
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
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Exploit-DB