CVE-2025-65781
BaseFortify
Publication date: 2025-12-15
Last updated on: 2025-12-18
Assigner: MITRE
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| wekan_project | wekan | to 8.16 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-287 | When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct. |
| CWE-400 | The product does not properly control the allocation and maintenance of a limited resource. |
Attack-Flow Graph
AI Powered Q&A
How can this vulnerability impact me? :
This vulnerability can impact you by allowing attackers to cause Denial of Service (DoS) on the Wekan application, potentially making the service unavailable by exhausting server resources. Additionally, attackers can spoof user identities by submitting arbitrary bearer tokens, which may lead to unauthorized access or actions within the application. [4]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring API requests to the Attachment API endpoints (e.g., /api/attachment/*) for unusual or non-terminating request bodies when a non-empty bearer token is used in the Authorization header. Detection involves checking for requests that use bearer tokens directly as user IDs and cause hanging or excessive resource usage. Specific commands are not provided in the resources, but network monitoring tools or logs can be inspected for long-running or stalled requests with Authorization bearer tokens. Additionally, verifying if the system is running Wekan version prior to 18.16 can indicate vulnerability presence. [4]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading Wekan to version 18.16 or later, where the vulnerability is fixed. The fix enforces strict authentication by requiring X-User-Id and X-Auth-Token headers, validates tokens securely, imposes request timeouts (30 seconds), limits request body sizes (50MB for uploads, 10MB for metadata), and ensures proper access control by verifying board membership. Until upgrade, monitoring and limiting API request sizes and durations, and restricting access to the Attachment API may help reduce risk. [2, 4]
Can you explain this vulnerability to me?
This vulnerability in Wekan's Attachment upload API treats any non-empty Authorization bearer token as a userId, causing the server to enter a non-terminating body-handling state. This flaw allows trivial application-layer Denial of Service (DoS) attacks and latent identity spoofing, where attackers can impersonate users by submitting arbitrary bearer tokens. The issue was fixed by requiring proper authentication headers, verifying hashed tokens, enforcing request timeouts and size limits, and ensuring access control. [4]