Wekan
CVE-2025-65778
HIGH
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain Wekan board upload access
-
DeliveryUpload file served as text/html
-
ExploitLure victim to open attachment
-
ExecutionExecute HTML/JS in app origin
-
ImpactSteal session token and perform CSRF
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Output encoding, context-aware escaping
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires that an attacker can upload an attachment to a Wekan instance (typically board membership / an authenticated account, though open-registration deployments lower this barrier) AND that a victim subsequently opens/views the attachment, which pre-18.16 is served inline with an attacker-controlled Content-Type (text/html) and no forced-download/nosniff/CSP-sandbox headers. Limiting factors: victim user interaction is mandatory (UI:R); only versions up to 18.15 in default configuration are affected; and 18.16 mitigates by forcing Content-Disposition: attachment, Content-Type: application/octet-stream, X-Content-Type-Options: nosniff, a sandboxed CSP, and blocking inline SVG rendering. |
| Impact | CVSS 3.1 rates this 8.1 (High) via AV:N/AC:L/PR:N/UI:R with C:H/I:H, reflecting a network-reachable stored XSS that can steal sessions/tokens and perform CSRF in the application's origin. However, the real-world risk is more moderate than the raw score suggests, and the signals partially conflict. No EPSS score, CISA KEV listing, or public POC was provided, so there is no evidence of active or imminent exploitation (no public exploit identified at time of analysis). The CVSS PR:N (unauthenticated) rating also appears optimistic: exploitation requires an attacker to UPLOAD an attachment, which in Wekan normally requires an authenticated board-member account - verify with vendor, as this likely should be PR:L. The UI:R requirement (a victim must open/view the malicious attachment) further limits mass exploitation. Net: a legitimate patch-worthy vulnerability, but a targeted insider/low-privilege-abuse vector rather than a mass-exploitable unauthenticated RCE-class issue; prioritize patching but not as an emergency unless Wekan is internet-exposed with open registration. |
| Exploit ScenarioDerived | An attacker with the ability to upload attachments to a Wekan board uploads a malicious file that is served back with an attacker-controlled Content-Type of text/html. When a victim user opens/views that attachment, the embedded HTML/JS executes in the Wekan origin, allowing the attacker to steal the victim's session token and issue CSRF actions as that user. No public exploit code was identified, but the mechanism is straightforward given the required user interaction. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Stored cross-site scripting in Wekan through version 18.15 lets an attacker who can upload a board attachment have it served inline under an attacker-controlled Content-Type (text/html) on the application's own origin, so the victim's browser executes attacker-supplied HTML/JavaScript in the Wekan session context when the attachment is opened. Successful exploitation enables session and token theft and lets the attacker drive authenticated CSRF-style actions as the victim; CVSS 3.1 scores this 8.1 (High) via AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N, and the assessed prerequisites are that the attacker can upload an attachment (typically board membership or any authenticated account, with open-registration deployments lowering that barrier) and that a victim subsequently views it, making mandatory user interaction the main limiting factor. The issue is fixed in Wekan 18.16, which forces attachment responses to download with Content-Type: application/octet-stream, Content-Disposition: attachment, X-Content-Type-Options: nosniff and a restrictive sandboxed CSP, and blocks inline SVG rendering; no public exploit code was identified at time of analysis and there is no CISA KEV listing.
RemediationAI
Upgrade to Wekan 18.16 or later, which is the vendor-released patch: https://github.com/wekan/wekan/blob/main/CHANGELOG.md#v816-2025-11-02-wekan--release. The specific upstream fix is commit e9a727301d7b4f1689a703503df668c0f4f4cab8 (https://github.com/wekan/wekan/commit/e9a727301d7b4f1689a703503df668c0f4f4cab8), which forces all attachment downloads to Content-Type: application/octet-stream with Content-Disposition: attachment, X-Content-Type-Options: nosniff and a sandboxed Content-Security-Policy, blocks inline SVG rendering, and re-enables strict server-side upload validation (MIME sniffing from file content, a dangerous-type denylist for text/html, SVG, XML and JavaScript types, and content scanning). If upgrading immediately is not possible, compensating controls are: restrict who can upload attachments by removing upload permission from untrusted or self-registered accounts (side effect: legitimate users lose attachment sharing); disable public self-registration so outsiders cannot gain the upload capability (side effect: onboarding becomes admin-driven); and, at the reverse proxy, rewrite responses for attachment paths so they are returned as Content-Type: application/octet-stream with Content-Disposition: attachment and X-Content-Type-Options: nosniff, plus a restrictive sandbox CSP (side effect: inline previews of images and avatars break, and proxy rules must be maintained as attachment routes change). Where uploads cannot be disabled, treat all attachments as untrusted, do not open them in a logged-in Wekan session, and consider serving Wekan attachments from a separate origin/domain so any successfully rendered payload does not share the application's session context. Note that blocking or stripping SVG and HTML uploads alone is only a partial mitigation because the Content-Type is attacker-controlled at serve time; the header hardening introduced in 18.16 is the durable fix. No vendor-released patch was available before 18.16, and no other patch version should be assumed.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Wekan is a Meteor-based open-source kanban application that stores uploaded board files and avatars through the ostrio:files collection package. The root cause is CWE-79 (Improper Neutralization of Input During Web Page Generation, i.e. cross-site scripting): attachments were persisted and later returned inline, with the response Content-Type derived from attacker-influenced upload metadata, so a file declared or detected as text/html (or SVG/XML variants) was rendered as active markup inside the Wekan origin rather than downloaded as inert data. Because the payload executes same-origin in the victim's authenticated browser context, it can read the app session, exfiltrate tokens, and issue state-changing requests (CSRF). The vendor's fix addresses both halves of the problem: the attachment serving path was changed so responses carry Content-Type: application/octet-stream, Content-Disposition: attachment, X-Content-Type-Options: nosniff and a sandboxing Content-Security-Policy; the universal attachment link generation was reworked to override the ostrio:files link method reliably; and server-side upload validation (models/fileValidation.js) was hardened so MIME detection uses actual file content, dangerous types (text/html, application/xhtml+xml, image/svg+xml, text/xml, application/xml, application/javascript, text/javascript) are held to a denylist, uploaded content is scanned for script tags, event handlers, javascript: URIs, iframes/objects/embeds, meta-refresh, foreignObject and XML entity/DTD constructs, oversized files that cannot be fully scanned are treated as unsafe, and SVG uploads are no longer rendered inline. The affected component family corresponds to the CPE cpe:2.3:a:wekan_project:wekan:*:*:*:*:*:*:*:*, covering all releases up to and including 18.15 in the default configuration.
Know when Wekan 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
AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
Uploading an attachment realistically requires an authenticated Wekan board account (PR:L), and a victim must open the malicious attachment (UI:R); XSS yields session theft and CSRF so C:H/I:H, A:N.
Primary rating from NVD.
CVSS VectorNVD
DescriptionNVD
An issue was discovered in Wekan The Open Source kanban board system up to version 18.15, fixed in 18.16. Uploaded attachments can be served with attacker-controlled Content-Type (text/html), allowing execution of attacker-supplied HTML/JS in the application's origin and enabling session/token theft and CSRF actions.
Executive ViewAI
Wekan versions up to 18.15 are vulnerable to a stored cross-site scripting flaw that allows attackers to execute malicious scripts in the context of a victim's authenticated session when they open a crafted attachment. This can lead to session hijacking, token theft, and unauthorized actions on behalf of affected users, potentially compromising sensitive board data and organizational workflows. Security leadership should prioritize patching to Wekan 18.16 to mitigate the risk of account takeover and data integrity issues.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
GitHub
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
Cross-Site Scripting occurs when an application accepts untrusted data and sends it to a web browser without proper validation or encoding.
Cross-Site Request Forgery exploits the automatic credential inclusion behavior of web browsers.
Affected Products (CPE)NVD
packages/wekan-ldap/server/ldap.js in Wekan before 4.87 can process connections even though they are not authorized by t
OS command injection in Wekan (the open-source Meteor-based kanban board) before version 9.07 lets an authenticated user
Authentication bypass in Wekan (open-source Meteor kanban) before version 9.46 lets an unauthenticated attacker imperson
A stored cross-site scripting (Stored XSS) vulnerability in file preview in WeKan before 6.75 allows remote authenticate
Wekan, open source kanban board system, between version 3.12 and 4.11, is vulnerable to multiple stored cross-site scrip
Account takeover in Wekan (open-source Meteor kanban) before 9.32 allows an attacker who controls an OIDC provider accou
Privilege escalation in Wekan open-source kanban (all versions prior to 9.89, dubbed 'SortBleed') allows any board membe
Privilege escalation in the self-hosted Wekan kanban board through version 18.15 allows any authenticated user to rewrit
Stored XSS in Wekan prior to v9.90 allows authenticated board members to upload HTML containing JavaScript disguised as
LDAP filter injection in WeKan before 8.19 allows remote unauthenticated attackers to manipulate LDAP search filters and
Privilege escalation in WeKan (versions prior to 8.35) allows authenticated board members with low privileges to perform
Wekan's outgoing webhook URL validator in versions 8.36 through 9.73 allows authenticated board members to bypass SSRF p
Exploit-DB