CVE-2024-1902
📋 TL;DR
This vulnerability allows removed users to modify organization names in lunary-ai/lunary by reusing old session tokens. Attackers can exploit this authorization flaw to make unauthorized changes to organizations they no longer belong to. All organizations using vulnerable versions of lunary-ai/lunary are affected.
💻 Affected Systems
- lunary-ai/lunary
📦 What is this software?
Lunary by Lunary
⚠️ Risk & Real-World Impact
Worst Case
Malicious former users could rename critical organizations, causing operational disruption, confusion, and potential data access issues for legitimate users.
Likely Case
Disgruntled former employees or users could rename organizations out of spite, requiring administrative cleanup and causing temporary confusion.
If Mitigated
With proper session invalidation and authorization checks, only current organization members can modify organization settings.
🎯 Exploit Status
Exploitation requires a valid but outdated authorization token from a previously authorized user.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: Commit d8e2e73efd53ab4e92cf47bbf4b639a9f08853d2 and later
Vendor Advisory: https://github.com/lunary-ai/lunary/commit/d8e2e73efd53ab4e92cf47bbf4b639a9f08853d2
Restart Required: Yes
Instructions:
1. Update lunary-ai/lunary to commit d8e2e73efd53ab4e92cf47bbf4b639a9f08853d2 or later. 2. Restart the application. 3. Force all users to re-authenticate to invalidate old tokens.
🔧 Temporary Workarounds
Manual session invalidation
allForce all users to log out and regenerate session tokens
# Clear session storage or invalidate all tokens in your deployment
API rate limiting
allImplement rate limiting on PATCH requests to orgs endpoint
# Configure rate limiting in your reverse proxy or application middleware
🧯 If You Can't Patch
- Implement middleware that validates user organization membership on every PATCH request to orgs endpoint
- Deploy a web application firewall (WAF) with rules to detect suspicious PATCH requests from recently removed users
🔍 How to Verify
Check if Vulnerable:
Test if a removed user's old token can still make PATCH requests to /orgs endpoint
Check Version:
git log --oneline -1
Verify Fix Applied:
Verify that removed users receive 403 Forbidden when attempting PATCH requests to /orgs endpoint
📡 Detection & Monitoring
Log Indicators:
- PATCH requests to /orgs endpoint from users not in current organization membership lists
- Multiple failed authorization attempts followed by successful PATCH
Network Indicators:
- Unusual PATCH request patterns to organization endpoints
- Requests using old authorization tokens
SIEM Query:
source="application.logs" AND (method="PATCH" AND uri="/orgs") AND user_id NOT IN (SELECT user_id FROM organization_members WHERE organization_id=?)